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Commissioner for Patents 

P.O. Box 1450 

Alexandria, VA 22313-1450 



Dear Commissioner: 



1. 



I am an inventor of claims 1 1-59 of the above referenced patent application. 



2. Claims 1 1-59 have been rejected under 35 USC 102(e) as anticipated by MuUer et 
al. (U.S. Patent 6,483,804) that has a reference date of March 1, 1999. 

3. Prior to the reference date of March 1, 1999, 1 conceived of the invention of claims 
1 1, 29, and 54 shown in the following: 

• Exhibit AO:Directory of documents 

• Exhibit Al: Technically Elite MeterFiow Accelerator Modules System 
Specification (Document MFASystem.pdf) 

« Exhibit A2: Technically Elite MeterFiow Accelerator Parser Module Specification 
(Document MFAParser.pdf) 

• Exhibit A3: Technically Elite MeterFiow Accelerator Analyzer Module 
Specification (Document MFAAnaiyze.pdf) 

• Exhibit A4: Protocol Tracking Summary (Document MFAProtocoILayout.pdf) 

A copy of each of Exhibits AO to A4 is attached. The dates on each such copy has been 
deleted* I confirm that the dates are all prior to March 1, 1999. These exhibits are as 
follows. 

Exhibit AO is a dated computer directory of documents that describe the design and tests to 
run the design on real data. 

Exhibit Al is the overall design of the system that implements the method claims 1 1 and 
54, and includes the elements of claim 29. 

Exhibit A2 is a detailed design of the parsing/extraction unit that carries out step (b) of 
claim 11, that corresponds to element (c): the parser subsystem of claim 29, and that 
carries out the parsing/extraction operations of element (b) of claim 54. 
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Exhibit A3 is a detailed design of the analyzer that carries out the operations of elements 
(c), (d) ,and (e) of method claim 29, that corresponds to elements (d), (e) and (f) unit 
parsing/extraction unit that carries out carries out the operations of elements (c), (d) ,and 
(e) of method claim 54, that corresponds to element (c): the parser subsystem of claim 29, 
and that carries out the parsing/extraction operations of element (b) of claim 54. 

Exhibit A4 is a summary of the protocols that the system can analyze. 

Note that Technically Elite was the name of the predecessor of the assignee of the present 
invention at the time. 

3. Prior to the reference date of March 1, 1999, 1 reduced to practice the invention of 
claims 1 1, 29, and 54 of the above referenced patent application as shown in the following 
documents: 

• Exhibit BO is a dated computer directory of test data and documents used 
tiierefore. 

• Exhibit Bl: Technically Elite MeterFlow Accelerator Modules Testbench 
Specification (Document MFATest.pdf in directory of Exhibit AO) 

• Exliibit B2: The first page of file big.cpL 

The cpl files (big.cpl, bigfgc3.cpl, bigfgpc.cpl, bigfpaylcpl, bigfpayl2.cpl, 
bigfpgrp.cpl, bigfpgrp2.cpl, bigfi-ag.cpl, bigfi*ag2.cpl, output cpl, Protocols.cpl, 
short.cpl, shrtfpg2.cpl, shrtfps3.cpl, shrtfps4.cpl, shrtfpsS.cpl, shrttunl.cpl) are files 
for the protocol compiler of all the actual protocols recognized by the system. 
These files include a description of the parser information for the parser to perform 
the parsing/extracting operation according to the protocol. They also contain the 
state processing states for the state operations of elements (d) and (e) of claim 54. 
The first page of one file is provided. 

• Exhibit B3: The first four pages of a printout of file MFATEST.HEX that contains 
the actual packets captured by the packet acquisition device described in element 
(a) of claims 1 1 and 54, and corresponding to the contents of element (b), the input 
buffer memory of claim 29. The packet acquisition device for the experiment was a 
SUN workstation cormected to a connection point of a network. 

• Exhibit B4: The file packets.txt that describes the nature of the packets in 
MFATEST.HEX. 

• Exhibit B5: The contents of files mfaptpkt.txt and mfaptpkt2,txt that are files that 
contain the elements that were extracted by the parsing/extracting of 

• Exhibit B6: The contents of files mfaptkey.txt and mfaptkey2.txt that are files that 
contain the keys that were generated from the extracted data (Exhibit B4) and used 
for looking up the flow-entry database per element (c) of method claims 1 1 and 54, 
which are operations carried out by the lookup engine of element (e) of claim 29. 
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• Exhibit B7: The first four pages of a printout of file MFATEST.TXT that includes 
the decoded packets that were generated by operation of the method that includes 
the elements of each of method claims 1 1 and 54, by an apparatus that includes the 
elements of claim 29. 

• Exhibit B8: Protocol Definition Language (PDL) Reference Guide (the document 
MFS-PDL-Reference.pdf) that provides a reference to the protocol definition 
language used in cpl files. 

• Exhibit B9: State-based Sub-Classification Overview (document MFS-State- 
Classification.pdf) that describes the states of some of the protocols that are 
supported. 

The invention functioned for its intended purpose by running the apparatus on a computer, 
and a program implementing the method on test data that was part of a node of a network. 

The above exhibits are each a copy. The date on each copy has been deleted, I confirm that 
the deleted dates are each prior to March 1, 1999. 

Therefore, and in summary, 1 declare tliat the inventions of claims 1 1, 29, and 54 were 
reduced to practice prior to the reference data of March 1, 1999. 

I hereby declare under penalty of perjury under the laws of the United States of America 

that all statements made herein of my own knowledge are true and that all statements made 
on infonnation and belief are believed to be true; and further that these statements were 
made with the knowledge that willftil false statements and the like so made are punishable 
by fine or imprisonment, or both, under Section 1001 of Title 18 of the United States Code 
and that such willful false statements may jeopardize the validity of the application or any 
patent issued thereon. 

Signed, 

March 1,2005 

Date Russell S. Dietz 

Address for correspondence: 
Dov Rosenfeld 

5507 College Avenue, Suite 2, 
Oakland, CA 94618 

Tel. 510-547-3378 

Fax: +1-510-291-2985; Email:dov@inventek.com 
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Technically Elite MeterFlow Accelerator Modules System 

Specification 




1 Introduction 



The Technically Elite MeterFlow Accelerator is a set of synthesizable modules designed to do wire speed 
hardware based application traffic recognition for Fast Ethernet and Gigabit Ethernet. Originally designed 
for RM0N2 network management the MeterFlow Accelerator also allows Layer 3 (Network) through 
Layer 7 (Application) visibility for switches and routers .The MeterFlow Accelerator poaches the network 
traffic and builds a "flow" database that is then extracted for further processing. Each flow consists of the 
information necessary to track the conversation between the two end points of the traffic. This 
conversation is also characterized and vital statistics counted. The resulting flow database is useful for 
many applications. Some of these include RM0N2 network management, traffic steering, quality of 
service, security, and service level management. 

1. 1 Technically Elite MeterFlow Accelerator Highlights 

« Synthesizable modules written in both the Verilog and VHDL 

• Processes up to Gigabit speeds 

• Complete traffic data 

• State based parallel processing architecture 

• Distributes work to eliminate bottlenecks 

• Layer 3 network protocols to dynamic transaction oriented applications at Layer 7 

• Scalable architecture for any size switch or probe 

• Can recognize over 2000 different protocols 

• Extensible to new protocols 

• Recognizes encapsulations 

• Open interface 

• Easy to use software tools including protocol compiler and C model 
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2 Overview 



The Technically Elite MeterFlow Accelerator Modules System Specification outlines the general system 
requirements. It provides an overview of how the modules interact with each other and external devices. It 
also provides guidance for the testing methodology to be used in the verification of the cores. 

The Technically Elite network analysis suite consists of three main components. These are the parser, the 
analyzer and software. The parser works on the information contained in a single packet. The analyzer 
builds flow information across multiple packets. The software consists of a compiler, a C model and a 
database of protocol information. The database delineates all the information needed by the parser to 
recognize the protocols and build the flow key. The database also delineates how each protocol's flow 
entry should be updated as well as the procedure to recognize multi-packet protocols (state processing). 
Also included in the module set is a host interface module. This module defines a burst oriented bus 
interface compatible with the Intel i960. This module can be easily modified to interface to other bus 
types. 

After initialization the network data first goes to the parser. The parser attempts to recognize the various 
possible protocols in a particular packet. It then builds a flow key data structure that is passed to the 
analyzer. The analyzer first attempts to find a particular packets related flow in its' database. Then using 
the information it gathered from previous packets in this flow and the current packets* data it updates the 
flows' data base entry. Once a flow has been completely recognized, updates consist of gathering statistics. 
On a regular basis the external system reads the flow data base for further processing. 

The parser and analyzer modules are RTL synthesizable modules written in both the Verilog and VHDL 
hardware description languages. Each major component of the cores has a matching testbench. The 
testbenches fully exercise the unit under test and provide an automated verification environment. Input 
stimulus files are automatically generated by the compiler and expected data files are automatically 
generated by the C model. 
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3 Top Level MeterFiow Accelerator Module Symbol 



Reset_N 
MCLK 

HostModSeLN 
HostWrite 
HostBlasUN 
HostWaiLN 

HostAddress(22:0] 
HostByteEn_N(7:0) 
^ HostDataln(63:0] 



•— MemClkIn 

MemDataln[63:0] 



Type 



DPPacketDelim 

DPDataStb^N 

DPKillPkLN 

DPDataI31:01 



HostReady.N 
HostDataOut[63:0] 



MemRAS^N[1:0) 
MemCAS^N[3:0) 
MemClkEn 
MemClkOut 
MemWR.N 
* MemBA 
MemDSF 
MemByteEn_N[7:0] 

Mem Address[ 11:0] 

MemDataOut(63:01 
MemDirRead 



DPReady.N — • 



Insthfiime 



4 Top Level MeterFiow Accelerator Module Pin Descriptions 



4.1.1.1 General Interface Signals 


Signal 


Dir 


Width 


Description 


Reset^N 


IN 


1 


Reset - active low. 

When this signal is active the module sets it's registers to 
their default condition and suspends operation. It will only 
respond to host access cycles. The DataPort interface will 
keep DPReady_N active to avoid problems for the external 
circuitry. 


MCLK 


IN 


1 


Module Clock. 

All internal and external transfers except for memory 
transfers are synchronized by this signal. 
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4.1. L2 Memory Interface 


Signal 


Dir 


Width 


Description 


MemClkIn 


IN 


1 


Memory clock in. 

This signal is used to generate the memory interface timing. 


MemRAS N 


OUT 


2 


Mem or V Row Address Strobe bus — active low 


MemCAS N 


OUT 


4 


Memory Column Address Strobe bus— active low. 


MemClkEn 


OUT 


1 


Memory Clock Enable. 

Some memories require this signal to be disabled for a 
certain amount of time after reset. 


MemClkOut 


OUT 


1 


Memory Clock Out. 

This signal is used by synchronous memory for all 
ot)erations MemClkIn is buffered and sent out on this oin. 
This helps reduce skew between this clock and the other 

signals. 


MemWR^N 


OUT 


1 


Memory Write - active low. 


MemBA 

MemDSF 


OUT 

OUT 


1 

~1 ' 


Memory Bank Address. 

Used by multi>bank memory to select the bank the current 
operation is to operate on. 
Memory Special Function select. 


MemByteEn^N 


out" 


"8 ~ ""^ 


Memory Byte Enable bus- active low. 


MemAddress 


12 


Memory Address bus. 


MemDataIn 


IN 




Memory Data Input bus. 


MemDataOut 


OUT 


64 "1 


Memory Data Output bus. 


MemDirRead 


OUT 


1 


Memory Data bus Direction is Read. 
This signal is used to control the tri-state enable on the 
bidirectional memory data bus. If MemDirRead is active 
data is coming into the module from the memory. If it is 
inactive the module is driving data out to the memory. 
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Signal 


Dir 


Width 


Description 


HostModSeLN 


IN 


1 


Host interface Module Select - active low. 
HostModSeLN is sampled on the rising edge of MCLK. If 
it is active, it signifies that the external host is attempting to 
access the module. 


HostWrite 


IN 


1 


Write. 

Write is sampled on the rising edge of MCLK. This signal 
is only valid when HostModSeLN is active. If this signal is 
active, the host is attempting to write to the module. Inactive 
this signal sign signifies a read from the module. It should 
also be used to control the direction of the host data bus if it 
is bidirectional. 


HostBIast.N 


IN 


1 


Burst Last - active low. 

HostBlast_N is sampled on the rising edge of MCLK. 
HostBlast^N tells the module that the current transfer is the 
last transfer in this burst. 


HostWait.N 


IN 


1 


Wait - active low. 

HostWait_N is sampled on the rising edge of MCLK. The 
host asserts HostWait_N when it wishes to slow transfers 
between itself and the module. This could also be used by 
additional interface logic to slow transfers so it can 
multiplex the bus down to a smaller size without additional 
FIFOs. If wait is active, HostReady_N is blocked. 


HostReady_N 


OUT 


1 


Ready - active low. 

HostReady_N should be sampled on the rising edge of 
MCLK, The module returns HostReady_N when the 
current cycle is completed. For a write operation, 
HostReady_N means that the HostDataln bus has been 
latched. For a read operation HostReady_N means that the 
requested data is on the HostDataOut bus and is valid. 
HostReady^N is blocked by HostWait_N. 


HostAddress 


IN 


23 


Host Address bus. 

HostAddress is sampled on the rising edge of MCLK if 
HostModSeLN is active. This bus defines the first address 
in this burst to access in the 64 Megabyte address space of 
the module. See Section x.x.x for the Address Utilization 

Map. 


HostByteEn^N 


In 




Host Byte Enable bus - Active low. 

HostWait_N is sampled on the rising edge of MCLK. 


HostDataln 


IN 


64 


Host Data Input bus. 

HostDataln is sampled on the rising edge of MCLK if 
HostWrite is active and HostWait_N is inactive. 


HostDataOut 


OUT 
i 


64 


Host Data Output bus. 

HostDataOut should be sampled on the rising edge of 
MCLK. Data on this bus is valid during a read cycle when 
HostReady_N is active. 
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4.1.1.4 Data Port Interface 


Signal 


Dir 


Width 


Description 


DPPacketDelim 


IN 


1 


Data Port Packet Delimiter. 

This signal should be driven active when the external logic 
wants to send a oacket to the module DPPackeiDelim 
should remain active during the entire packet transfer. 
DPPacketDelim must go inactive for one clock between 
packets. 


DPDataStb_N 


IN 


1 


Data Port Data Strobe. 

When active, this signal tells the module that data on the 
DPData bus is valid. If DPReady_N was inactive at the end 
of thf* nrevioiK rvcle DPDatuSth N should not hp Hrivpn 
active. If DPReady^N goes inactive in the same cycle as 
DPDataStb_N, then the module will latch the incoming 
data so that no data is lost. 


DPKillPkt„N 


IN 


1 


Data Port Kill Packet. 

If this signal becomes active while DPPacketDelim is 

Jirtivp thf* mofliilp will attpmnt fn <;fnn nrnrps^iinp thp 

civil lllV lliv'VJUIV VVIil ClllVlll|yl \\J ^1 ^.yTWool 1 1^ lllv 

current packet and flush it's input FIFO. If however, parsing 
of the packet is completed, the packet will not be able to be 
recalled. This should only be a problem in a *cut through* 
implementation. 


DPReady_N 


OUT 


1 


Data Port Ready - active low. 

This signal when driven active means that the module can 
accept new data. If however the modules' input FIFO is 
filled, DPReady_N will be driven inactive. To prevent 
overruns, DPReady^N will go inactive when the module 

can actually accept one more data transfer. 


DPData 


IN 


32 


Data Port Data bus. 



5 MeterFlow Accelerator Modules Block Diagrams 

The following page is the top level block diagram for the MeterFlow Accelerator Module. 
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6 Description of iVIoduies and Software 



6.1 Parser Module 

6.1.1 Parser Module Highlights 

Builds key and payload data structure for analyzer (flow key) 
Scaleable protocol pattern recognition engine 
Supports from 1 to 2048 simultaneous unique protocol patterns 
At 62.5 MegaHertz can process up to 1.5 MegaPackets per second 
Accepts protocol database output from Meter Flow compiler 

6.1.2 Parser Module Symbol 



PAR.TOP 





Reset_N 






MCLK 






AnalyzerReady 






DPPacketDelfm 






DPDataStb.N 






DPKiIIPkt_N 


ParserKeyDelim 




DPData[31:0} 


ParserDataAvail 






ParserSeLN 


ParserData[63:0) 




HostWrite 


DPReady_N 




HostBlasUN 


ParHostReady.N 




HostWaiLN 


ParHostOataOut[63:0] 




HostAddress(13:0] 






HostByteEn.N[7:0} 





^ HostDatalnt63:0] 



6.1.3 Parser Module Description 

The parser module consist of two main sub-modules. These are the pattern recognition engine and the 
slicer. The parser module pouches the network data through the DataPort interface. The data is first 
processed by the pattern recognition engine. This engine consists of a database and a comparison engine. 
The database can reside in ROM or RAM. If the database is in a RAM the parser can be programmed to 
recognize new protocols or a different set of protocols. 

The set of specified protocols defines a tree of linked nodes. Each protocol is either a parent node or a 
terminal node. A protocol is a parent node if it links to other protocols that can be contained in it. For 
example IP is a parent to UDP. As each protocol is recognized, the pattern recognition engine emits a 
unique protocol identifier. It also emits a process code that the slicer uses to build the flow key. 

The slicer extracts information from the packet to build the flow key. For example, it will extract the 
source and destination addresses from the packet and pack them into the flow key data structure. It may 
also process certain parts of the packet to speed up flow processing performed by the analyzer. It will build 
a hash value from certain parts of the packet to speed looking up the flow in the analyzers* database. 
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6.1.4 Parser Module Pin Descriptions 



6.1.4.1 General Interface Signals 


Signal 


Dir 


Width 


Description 


Reset_N 


IN 


1 


Reset - active low. 

When this signal is active the parser sets it's registers to 
their default condition and suspends operation. It will only 
respond to host access cycles. The DataPort interface will 
keep DPReady_N active to avoid problems for the external 
circuitry. 


MCLK 


IN 


1 


Module Clock. 

All internal and external transfers except for memory 
transfers are synchronized by this signal. 




6.1.4.2 Analyzer Interface 


Signal 


Dir 


Width 


Description 


AnalyzerReady 


IN 


1 


Analyzer Ready. 

This signal tells the parser that the analyzer can accept data. 


ParserKeyDelim 


OUT 


1 


Parser Key Delimiter. 

The ParserKeyDelim signal becomes active when the first 
quadword of a new key is ready to transfer to the analyzer. It 
goes inactive when the last quadword of the key is 
transferred. 


ParserDataAvail 


OUT 


1 


Parser Data Available. 

If this signal is active the data on the ParserData bus is 
valid. 


ParserData 


OUT 


64 


Parser Data bus. 
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6.1.4.3 Data Port Interface 


Signal 


Dir 


Width 


Description 


DPPacketDelim 


IN 


1 


Data Port Packet Delimiter. 

This signal should be driven active when the external logic 
wants to send a packet to the parser. DPPacketDelim 
should remain active during the entire packet transfer. 
DPPacketDelim must go inactive for one clock between 


DPDataStb.N 


IN 


1 


Data Port Data Strobe. 

When active, this signal tells the parser that data on the 
DPData bus is valid. If DPReady_N was inactive at the end 
of the previous cycle, DPDataStb^N should not be driven 
active. If DPReady_N goes inactive in the same cycle as 
DPDataStb_N, then the parser will latch the incoming data 

iriaL IIU Udla la lUol. 


DPKillPkt.N 


IN • 


1 


Data Port Kill Packet. 

If this signal becomes active while DPPacketDelim is 
active, the parser will attempt to stop processing the current 
packet and flush it's input FIFO. If however, parsing of the 
packet is completed, the packet will not be able to be 
recaiieu. iiiid diiuuiu uiuy uc a pruuiciii iii a cui uiiuugii 
implementation. 


DPReady_N 


OUT 


1 


Data Port Ready - active low. 

This signal when driven active means that the parser can 
accept new data. If however the parser*s input FIFO is filled, 
DPReady_N will be driven inactive. To prevent overruns, 
DPReady_N will go inactive when the parser can actually 
accept one more data transfer. 


DPData 


IN 


32 


Data Port Data bus. 
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6.1.4.4 Host Interface Signals 


Signal 


Dir 


Width 


Description 


ParserSel_N 


IN 


1 


Parser Select - activf* low 

ParserSeLN is sampled on the rising edge of MCLK. If it 
is active, it signifies that the external host is attempting to 
access the parser. 


HostWrite 


IN 


1 


Write. 

Write is sampled on the rising edge of MCLK. This signal 
is only valid when ParserSel _N is active. If this signal is 
active, the host is attempting to write to the parser. Inactive 

this signal sipn signifies a read from fht* nar^er 


HostBlast^N 


IN 


1 


Burst Last - active low. 

HostBlast.N is sampled on the rising edge of MCLK. 
HostBlast^N tells the parser that the current transfer is the 
last transfer in this burst. 


HostWait.N 


IN 


1 


Wait - active low. 

HostWait_N is sampled on the rising edge of MCLK. The 
host asserts HostWait_N when it wishes to slow transfers 
between itself and the parser. 


ParHostReady^N 


OUT 


1 


Parser to Host Ready - active low. 

ParHostReady_N should be sampled on the rising edge of 
MCLK. The parser returns ParHostReady^N when the 
current cycle is completed. For a write operation, 
ParHostReady_N means that the HostDataIn bus has been 
latched. For a read operation ParHostReady^N means that 

the reniie<*ted dat?i is on the ParHn^fDjifiiOiit hns anH is 

valid. ParHostReady.N is blocked by HostWait_N. 


HostAddress 


IN 


13 


Host Address bus. 

HostAHHress is samnlerl nn the risincr pHctp of IVir^f IC 'if 

ParserSeLN is active. This bus defines the first address in 
this burst to access in the 64 Kilobyte address space of the 
Parser. See Section x.x.x for the Address Utilization Map. 


HostByteEn_N \ IN 




Host Byte Enable bus - Active low. 

HostWait_N is sampled on the rising edge of MCLK. 


HostDataIn 


IN 


64 


Host Data Input bus. 

HostDataIn is sampled on the rising edge of MCLK if 
HostWrite is active and HostWait_N is inactive. 


ParHostDataOut 


OUT 


64 


ParserHost Data Output bus. 

ParHostDataOut should be sampled on the rising edge of 
MCLK. Data on this bus is valid during a read cycle when 
ParHostReady.N is active. 
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6.2 Analyzer Module 

6.2.1 Analyzer Module Highlights 

• "Flexible" Rule-based Traffic Classification 

• State-based Tracking of Traffic 

• Multiple Packets for Layer Processing 

• Internal Cache and Memory Controller (32 - 64KB) 

• Direct High Bandwidth (64 bit) Memory Interface 

• Up to 1 6MB of memory (75K Flows) 

• SG/SDRAM Support 

• Programmable Rules/State Engine 

• Selectable Protocols in Flows 

• Future Protocols Support 

• Scalable System Design 

6.2.2 Analyzer Module Symbol 



ANA.TOP 



Reset_N 
MCLK 



MemCikIn 
MemData)n[63:0] 



AnatyzerSeLN 
HostWrite 
HoslBlast_N 
HostWaiLN 



MemRAS_N[1:0) 

MemCAS^N[3:0) |— 

MemClkEn 
MemClkOut 
MemWR_N 
MemBA 
MemDSF 

MemByteEn.N[7:0] 
Mem Adcldress[ 11:0] 



MemDataOut[63:0] 

MemDirRead 
AnaHostReady.N 



HostAddress[21:0] 
HostByteEn_N[7:0] 

HostDataln[63:0] AnaHostDataOut[63:0) 



«^ ParserKeyDelim 

Pa rserData Avail AnaiyzerReady 
^ ParserData[63:0) 
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6.2.3 Analyzer Module Description 

The analyzer module consists of the flow lookup engine, the flow insertion/deletetion engine, the simple 
rules engine, the complex rules engine, the caching memory controller, the host update controller and the 
process synchronizer. Each of these sub-modules work in parallel to create and update flows. 

As a flow key enters the analyzer, the lookup engine attempts to find it in the flow database. If the flow 

exists, the lookup engine retrieves the flow from the caching memory controller. It then makes a decision 
based on the state information included in the flow entry to either send it to the simple rules engine, the 
complex rules engine or to update the flow entry itself. This updating consists of adding values to counters 
in the flow database entry. If a flow does not exist, .the flow key is sent to the flow insertion/deletetion 
engine which adds the flow to the database. Based on the flow key information the flow 
insertion/deletetion engine may be also send the new flow to one of the rules engines for processing. 

The simple rules engine updates the flow based on the current state and the flow key information. The 
complex rules engine processes multi packet protocol recognition. It may have to search through a series 
of possible states to determine the flow's actual state. The result of the complex engine's processing is a 
consolidated flow entry. For example, a PointCast session will open multiple conversations that on a 
packet by packet basis look like separate flows. Since each conversation is merely a subflow under the 
PointCast master flow, a single flow that consolidates all of the information for the flow is desired. 

The caching memory controller can be setup to work with various configurations of SDRAM or SGRAM. 
It uses it's cache to optimize memory bandwidth. On a typical network the packets will have a certain 
amount of congruity. This means that the cache can have a high hit rate. 



6.2.4 Analyzer Module Pin Out 



6.2.4.1 General Interface Signals 


Signal 


Dir 


Width 


Description 


Reset_.N 


IN 


1 


Reset - active low. 

When this signal is active the analyzer sets it*s registers to 
their default condition and suspends operation. It will only 
respond to host access cycles. 


MCLK 


IN 


1 


Module Clock. 

All internal and external transfers except for memory 
transfers are synchronized by this signal. 
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6«2.4.2 Memory Interface 


Signal 


Dir 


Width 


Description 


MemClkIn 


IN 


1 


Memory clock in. 

This signal is used to generate the memory interface timing. 


MemRAS^N 


OUT 


2 


Memory Row Address Strobe bus - active low. 


MemCAS N 


OUT 


4 


Memorv Column Address Strobe bus— active low 


iTACllI^IAlltll 


OUT 


1 


Memorv Clock Enable 

Some memories require this signal to be disabled for a 
certain amount of time after reset. 




OUT 




Memorv Clock Out 

This signal is used by synchronous memory for all 
nnprations MemClkIn is buffered and sent out on this nin 
This helps reduce skew between this clock and the other 

signals. 


MemWR_N 


OUT 


1 


Memory Write - active low. 


MemBA 


OUT 


1 


Memory Bank Address. 

Used by multi-bank memory to select the bank the current 
operation is to operate on. 


MemDSF 


OUT 


1 


Memory Special Function select. 


MemByteEn_N 


OUT 


8 


Memory Byte Enable bus- active low. 


MemAddress i OUT 


12 


Memory Address bus. 


MemDataln j IN 


64 1 Memory Data Input bus. 


MemDataOut i OUT 


64 ! Memory Data Output bus. 


MemDirRead | OUT 

■ 

I 


1 1 Memory Data bus Direction is Read. 

1 This signal is used to control the tri-state enable on the 
1 bidirectional memory data bus. If MemDirRead is active 
i data is coming into the analyzer from the memory. If it is 
j inactive the analyzer is driving data out to the memory. 
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6.2.4.3 Host Interface Signals 


Signal 


Dir 


Width 


Description 


AnalyzerSeLN 


IN 


1 


Host interface Analyzer Select - active low. 
AnalyzerSel_N is sannpled on the rising edge of MCLK. If 
it is active, it signifies that the external host is attempting to 
access the analyzer. 


HostWrite 


IN 


1 


Write. 

Write is sampled on the rising edge of MCLK. This signal 
is only valid when AnalyzerSel_N is active. If this signal is 
active, the host is attempting to write to the analyzer. 
Inactive this signal sign signifies a read from the analyzer. It 
should also be used to control the direction of the host data 
bus if it is bidirectional. 


HostBlast„N 


IN 


1 


Burst Last - active low. 

HostBIast_N is sampled on the rising edge of MCLK. 
HostBlast_N tells the analyzer that the current transfer is 
the last transfer in this burst. 


HostWait.N 


IN 


1 


Wait - active low. 

HostWait^N is sampled on the rising edge of MCLK. The 

host asserts HostWait_N when it wishes to slow transfers 
between itself and the analyzer. This could also be used by 
additional interface logic to slow transfers so it can 
multiplex the bus down to a smaller size without additional 
FIFOs. If wait is active, HostReady_N is blocked. 


AnaHostReady.N 


OUT 


1 


Analyzer to Host Ready - active low. 
AnaHostReady _N should be sampled on the rising edge of 
MCLK. The analyzer returns AnaHostReady _N when the 
current cycle is completed. For a write operation, 
AnaHostReady _N means that the HostDataIn bus has 
been latched. For a read operation AnaHostReady N 
means that the requested data is on the HostDataOut bus 
and is valid AnaHostReadv N is blocked bv Host Wait N 


HostAddress 


IN 


22 


Host Address bus. 

HostAddress is sampled on the rising edge of MCLK if 
AnalizerSel__N is active. This bus defines the first address 
in this burst to access in the 32 Megabyte address space of 
the analyzer. See Section x.x.x for the Address Utilization 








Map. 


HostByteEn^N 


''in'''"' 


8 


Host Byte Enable bus - Active low. 

HostWait^N is sampled on the rising edge of MCLK, 


HostDataIn 


In 


"64 


Host Data Input bus. 

HostDataIn is sampled on the rising edge of MCLK if 
HostWrite is active and HostWait N is inactive. 


AnaHostDataOut 


OUT 




Analyzer Host Data Output bus. 

AnaHostDataOut should be sampled on the rising edge of 
MCLK. Data on this bus is valid during a read cycle when 
AnaHostReady „N is active. 
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6.2.4.4 Parser Interface 


Signal 


Dir 


Width 


Description 


AnalyzerReady 


OUT 


1 


Analyzer Ready. 

T^hic ciQnnl tpllc thp nnrcpr thsif tViA sinii1\/7i3r nan t^nn^nf Aafci 
lllla Mglial Iwilo lilC yaldCI llldl IIIC allaiy£.cr Lall dL'CCpi Ualu» 


ParserKeyDelim 


IN 


1 


Parser Key Delimiter. 

The ParserKeyDelim signal becomes active when the first 
quadword of a new key is ready to transfer to the analyzer. It 
goes inactive when the last quadword of the key is 
transferred. 


ParserDataAvail 


IN 


1 


Parser Data Available. 

If this signal is active the data on the ParserData bus is 

valid. 


ParserData 


IN 


64 


Parser Data bus. 
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6.3 Host Interface Module 

6.3. 1 Host Interface Module Highlights 

• i960 style burst interface 

• Easily modified for connection to other buses 

6.3.2 Host Interface Symbol 



HI TOP 



Reset_N 
MCLK 

HostModSeLN 

HostBlast_N 

HostWait^N 

AnaHostReady_N 

ParHostReady.N 

HostAddress[22:0] 
AnaHostDataOut[63:0] 

ParHostDataOut[63:0] 



AnalyzerSeLN 
ParserSeLN 

HostDataOut[63:0] 

HostReady_N 



6.3.3 Host Interface Module Description 

The Host Interface module contains the host data multiplexer to select either the parser or the analyzer 
data bus. It also decodes the host address to create ParserSeLN or AanlyzerSeLN. 

6.3.4 Host Interface Module Pin Out 



6.3.4.1 General Interface Signals 


Signal 


Dir 


Width 


Description 


Reset_N 


IN 


1 


Reset - active low. 

When this signal is active the analyzer sets it's registers to 
their default condition and suspends operation. It will only 
respond to host access cycles. 


MCLK 


IN 


1 


Module Clock. 

All internal and external transfers except for memory 
transfers are synchronized by this signal. 
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6.3.4.2 Host Interface Signals 


Signal 


Dir 


Width 


Description 


AndlvzerSel N 


OUT 


1 


AnalyzerSeLN is sampled on the rising edge of MCLK. If 
it is active, it signifies that the external host is attempting to 
access the analyzer. 






1 


Parcpr Qp]<*r>t cknt\\!t* lr\\x/ 
ralL^CI OCICCI aLllVC lUW. 

ParserSeLN is sampled on the rising edge of MCLK. If it 
is active, it signifies that the external host is attempting to 
access the parser. 


HostBlast.N 


IN 


1 


Burst Last - active low. 

HostBIast_N is sampled on the rising edge of MCLK. 
HostBlast_N tells the analyzer that the current transfer is 
the last transfer in this hurst 


HostWait_N 


IN 


1 


Wait - active low. 

HostWait_N is sampled on the rising edge of MCLK. The 
host asserts HostWait_N when it wishes to slow transfers 
between itself and the analyzer. This could also be used by 
additional interface logic to slow transfers so it can 
multiplex the bus down to a smaller size without additional 
FIFOs. If wait is active, HostReady_N is blocked. 




IN 


1 


Analvzer to Host Readv — active low 
AnaHostReady _N should be sampled on the rising edge of 
MCLK. The analyzer returns AnaHostReady _N when the 
current cycle is completed. For a write operation, 
AnaHostReady _N means that the HostDataIn bus has 
been latched. For a read operation AnaHostReady _N 
means that the requested data is on the HostDataOut bus 
and is valid. AnaHostReady _N is blocked by HostWait_N. 




TM 


1 


r aloCl lU nuol IvCauy — awlivc luw. 

ParHostReady_N should be sampled on the rising edge of 
MCLK. The parser returns ParHostReady_N when the 
current cycle is completed. For a write operation, 
ParHostReady_N means that the HostDataIn bus has been 
latched. For a read operation ParHostReady_N means that 
the requested data is on the ParHostDataOut bus and is 
valid. ParHostReady_N is blocked by HostWait_N. 




OUT 


1 


Readv — active low 

HostReady^N should be sampled on the rising edge of 
MCLK. The module returns HostReady_N when the 
current cycle is completed. For a write operation, 
HostReady_N means that the HostDataIn bus has been 
latched. For a read operation HostReady^N means that the 
reouested data is on the HostDataOut bus and is valid 
HostReady_N is blocked by HostWait.N. 


HostAddress 


IN 


23 


Host Address bus. 

HostAddress is sampled on the rising edge of MCLK if 
AnalizerSeLN is active. This bus defines the first address 
in this burst to access in the 64 Megabyte address space of 
the analyzer. See Section x.x.x for the Address Utilization 
Map, 
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AnaHostDataOut 


i IN 

1 


64 


! Analyzer Host Data Output bus. 

1 AnaHostDataOut should be sampled on the rising edge of 
[ MCLK. Data on this bus is valid during a read cycle when 
1 AnahlostKeaay _N is active. 


ParHostDataOut 


j IN 

1 

; 


64 


1 ParserHost Data Output bus. 

\ FarHostUataOut should be sampled on the rising edge of 

t Tfc M *■ y«\ . • I'll* 1 1 A 

; MCLK. Data on this bus is valid during a read cycle when 




1 

'out T64 


j r^arnosiKcaay_i>i is acuve. 


HostDataOut 


! Host Data Output bus. 








! HostDataOut should be sampled on the rising edge of 




; 




1 MCLK. Data on this bus is valid during a read cycle when 




! 




! HostReady.N is active. 



MeterFlow Accelerator Modules System Specification lg.doc 
Confidential Page 19 of 22 



Technicall y Elite CONFID]^^^^ 



6.4 MeterFlow Compiler 

6.4.1 MeterFlow Compiler Highlights 

• ANSI compatible C implementation 

• Simple Packet Description Language 

• Technically Elite supplied Packet Description Language files for all common protocols 

• Any or all protocols can be included 

• Automatically generates parser module pattern recognition database 

• Automatically generates slicer instructions 

• Automatically generates unique protocol identifiers for use throughout system 

• Automatically generates analyzer programming 

• Automatically generates test input stimulus 

6.4.2 MeterFlow Compiler Description 

The MeterFlow Compiler generates all the information needed to program the MeterFlow accelerator. It's 
input is a set of files that define the protocols to recognize and the target system. It can also be used by the 
engineer to define the size of the databases required to support a certain set of protocols. The output of the 
compiler is a set of files used to program each part of the MeterFlow Accelerator. 

The compiler first reads the protocol definition files defined in the protocol list file and creates a tree 
defining each protocols relationship to the others. Protocols with the same name are assumed to be the 
same. For example, FTP under UDP and TCP are condensed into a single entry linked to both parent 
protocols. The compiler then reads the hardware definition file or uses a default maximum definition. It 
then searches the protocol space to find a solution. If a solution is found that fits into the hardware 
constraints, the compiler outputs database in a form that can be loaded into either the testbenches, the C 
model, or the hardware. 

If the t option is selected, the compiler will generate an input stimulus file for the testbenches. This file 
contains a series of packets one for each protocol in the protocol list. 

6.4.3 MeterFlow Compiler Invocation 
MFC <options> 



6.4.3.1 Options 



Option 


Name 


Description 


i < filename> 


Protocol list 
filename 


The protocol list file contains the names of each protocol to be 
included in this run. The default is MeterFlow.pl. The names must 
match the filename prefix of the protocol definition language file 
associated with that protocol. For example, if the TCP protocol is to be 
included, and the file is called TCP.PDL, the protocol list file should 
contain the line: 
I TCP; 

If the children of TCP are to be included they can be added 
automatically by replacing the above line with: 
I TCP c; 

Child protocols can be excluded by the following line as a example: 
EFTP; 
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0 <prefix> 


Output file 
prefix 


The output file prefix allows the user to change the start of the 
filename of the output files. The default is MeterFlow. 


d <filename> 


Hardware 
definition 
filename 


This input file is used by the compiler to constrain processing to the 
available hardware resources. If the compiler cannot find a solution at 
the effort level it will output a set of files with the best solution it 
found and report an error. 


e <n> 


Effort 


N is a number from 1 to 5. The default is 3. An effort level of 5 tells 
the compiler to exhaust the search space. 


t 


Generate 
input 

stimulus file 


This option generates a file that can be run through the C model to 
generate expected output data. Then both files can be run through the 
testbenches for automated testing of the modules. 



6.5 MeterFlow C Model 

6.5.1 MeterFlow C Model Highlights 

• ANSI compatible C implementation 

• Models the MeterFlow Accelerator modules 

• Outputs expected data for the testbenches 

• Excepts the same input files as the testbenches 



6.5.2 MeterFlow C Model Description 

The MeterFlow C Model reads the same files used by the modules and emulates them. It is used to 
generate expected data for the automated testbenches included with the modules. 

6.5.3 MeterFlow C Model Invocation 

MCM <options> 



6.5.3.1 Options 



Option 


Name 


Description 


i < filename> 


Input 

filename 
prefix 


The input file prefix allows the user to change the start of the filename 
of the input files. The default is MeterFlow. 


0 <prefix> 


Output file 
prefix 


The output file prefix allows the user to change the start of the 
filename of the output files. The default is MeterFlow. 


d <filename> 


Hardware 
definition 
filename 


This input file is used by the C model to emulate the available 
hardware resources. 



7 MeterFlow Accelerator Single Chip Implementation Top Level 

Schematic 
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Revision History 


Version 




Description 


0.9 


^^^^ 


First release 


1.0 




Rev 1 
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1 Introduction 

This document is designed to be the repository for all information related to the MeterFlow Accelerator 
Parser Module. This specification is designed to provide the engineer with enough information to fully 
implement the module. There will be revisions during and after the implementation process that will be 
reflected in this document. 

Each part of this specification describes a different aspect of the module. It concentrates on the interfaces 
between the parser module and the other parts of the system. The other parts of the system include the 
analyzer module, the host interface module and importantly the software that models, programs and tests 
the system The key to a successful implementation is the interfaces between modules and between sub- 
module and sub-module. Each interface is described in detail. Any changes to the interfaces may affect the 
entire module and even the entire system. Care must be taken that each interface is understood completely 
before implementation is begun. 



2 Technically Elite MeterFlow Accelerator Parser Module 
Highlights 



• Synthesizable modules written in both the Verilog and VHDL 

• Scalable architecture for any size switch or probe 

• Can recognize over 2000 different protocols 

• Extensible to new protocols 

• Recognizes encapsulations 

• Builds key and payload data structure for analyzer (flow key) 

• Scaleable protocol pattern recognition engine 

• At 62.5 MegaHertz can process up to 1 .5 MegaPackets per second 

• Accepts protocol database output from MeterFlow compiler 
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3 Architectural Overview 

The parser module consist of two main sub-modules. These are the pattern recognition engine (PRE) and 
the slicer. The PRE analyzes the packet and the slicer builds the flow key from the packet and instructions 
from the pattern recognition engine .The parser has been split into two parts for several reasons. First and 
foremost, the split correctly partitions the functions to allow maximum reuse of silicon across the over two 
thousand protocols that can be supported. Another advantage of the split architecture is that the compiler 
can analyze the three dimensional space occupied by the offset, level, and pattern data of the specified 
protocols and compact the databases used in the parser module. The set of specified protocols defines a 
tree of linked nodes. Each protocol is either a parent node or a terminal node. A protocol is a parent node 
if it links to other protocols that can be contained in it. For example IP is a parent to UDP. Protocols can 
be the children of several parents. If a unique node was generated for each of the possible parent/child 
trees, the database would explode exponentially. Instead, child nodes are shared among multiple parents 
thus compacting the database.. Finally the PRE can be used on it's own when only protocol recognition is 
required. 

The parser module pouches the network data through the DataPort interface. The data is first processed by 
the pattern recognition engine. This engine consists of a comparison engine and a database. The 
comparison engine has a first stage that checks the protocol type field to determine if it is an 802.3 packet 
and the field should be treated as a length. If it is not a length, the protocol is checked in the second stage. 
This is the only protocol level that is not programmable. This is because the detection of the protocol at 
this level is simple and well defined. It is implemented with partial CAMs that return a node identifier if 
hit. This second stage has two full sixteen bit CAMs defined for future protocol additions. After this 
detection is completed the engine initializes Current Offset Pointer (COP) to the next part of the packet 
that needs to be checked. The node identifier from the previous stage and the data pointed to by the COP 
are used by the PRE to lookup an entry in the database. As each protocol is recognized, the pattern 
recognition engine emits a unique protocol identifier. It also emits a process code that the slicer uses to 
build the flow key. This process is repeated until the node identifier's Terminal bit is set. At that point the 
PRE has completely recognized the protocols in the packet and readies itself for the next packet. 

The slicer extracts information from the packet to build the flow key. For example, it will extract the 
source and destination addresses from the packet and pack them into the flow key data structure. It may 
also process certain parts of the packet to speed up flow processing performed by the analyzer. It will build 
a hash value from certain parts of the packet to speed looking up the flow in the analyzers' database. The 
slicer transfers data from it's input Buffer to it's output Buffer based on the sequence of instructions in it's 
instruction database. When the PRE recognizes a protocol it outputs both the protocol identifier and a 
process code to the slicer. The protocol identifier is added to the flow key and the process code is used to 
fetch the first instruction from the instruction database. Instructions consist an operation code and usually 
source and destination offsets as well as a length. The offsets and length are in bytes. A typical operation 
is the MOVE instruction. This instruction tells the slicer to copy n bytes data unmodified from the input 
Buffer to the output Buffer. The slicer contains a byte-wise barrel shifter so that the bytes moved can be 
packed into the flow key. The slicer contains another instruction called HASH. This instruction tells the 
slicer to copy from the input Buffer to the HASH generator. The result from the HASH generator is always 
written into the first two bytes of the flow key. It is used to accelerate the lookup of the flow in the 
analyzers flow database. Once the flow key is completed, the slicer transfers it to the analyzer for further 
processing. 

The parser module databases can reside in ROM or RAM. If the databases are in a RAM the parser can be 
programmed to recognize new protocols or a different set of protocols. 
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3.1 Bandwidth requirements 

The target throughput for the MeterFIow Accelerator running at 62.5 Megahertz is 1.5 million packets per 
second (PPS). This is the sustained maximum throughput of a single Gigabit channel. At this rate the 
parser module has 41.6 cycles to process each packet. In order to reduce the need for front end buffering 
external to the parser module, the architecture has been designed to complete the protocol recognition 
generation in no more than 36 cycles. Since there could be up to 12 different protocols in each to be 
processed, the parser module has been designed to average three cycles per protocol. This is the very worst 
case because a packet that has twelve levels of protocols in it will most likely be much larger than the 
minimum packet size. This can be used as to advantage again in the reduction of external buffering. The 
slicer must also complete the flow key generation within 36 cycles to keep the system in balance and 
unstalled. This however can be extended if the payload copying instructions run to there maximum values. 

The average packet will have between 4 and 5 levels of protocol with no encapsulations. At three cycles 
per protocol the PRE will use only 15 cycles to complete a packet. This means that the PRE has a typical 
sustained throughput of over three million packets per second. 
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3.2 Architectural Block Diagram 
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4 Top Level MeterFiow Accelerator Parser Module Symbol 
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5 MeterFlow Accelerator Parser Module Top Level Pin 
Descriptions 



5.1.1.1 General Interface Signals 


Signal 


Dir 


Width 


Description 


Reset^N 


IN 


1 


Reset - active low. 

When this signal is active the parser sets it*s registers to 
their default condition and suspends operation. It will only 
respond to host access cycles. The DataPort interface will 
keep DPReady_N active to avoid problems for the external 
circuitry. 


MCLK 


IN 


1 


Module Clock. 

All internal and external transfers except for memory 
transfers are synchronized by this signal. 




5.1.1.2 Analyzer Interface 


Signal 


Dir 


Width 


Description 


AnalyzerReady 


IN 


1 


Analyzer Ready. 

This signal tells the parser that the analyzer can accept data. 


ParserKeyDelim 


OUT 


1 


Parser Key Delimiter. 

The ParserKeyDelim signal becomes active when the first 
quadword of a new key is ready to transfer to the analyzer. It 
goes inactive when the last quadword of the key is 
transferred. 


ParserDataAvail 


OUT 


1 


Parser Data Available. 

If this signal is active the data on the ParserData bus is 

valid. 


ParserData 


OUT 


64 


Parser Data bus. 
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5. 1 . 1.3 DataPort Interface 


Signal 


Dir 


Width 


Description 


DPPacketDelim 


IN 


1 


DataPort Packet Delimiter. 

This signal should be driven active when the external logic 
wants to send a packet to the parser. DPPacketDelim 
should remain active during the entire packet transfer. 
DPPacketDelim must go inactive for one clock between 
packets. 


DPDataStb^N 


IN 


1 


DataPort Data Strobe. 

When active, this signal tells the parser that data on the 
DPData bus is valid. If DPReady^N was inactive at the end 
of the previous cycle, DPDataStb.N should not be driven 
active. If DPReady^N goes inactive in the same cycle as 
DPDataStb^N, then the parser will latch the incoming data 
so that no data is lost. 


DPKillPkt_N 


IN 


1 


DataPort Kill Packet. 

If this signal becomes active while DPPacketDelim is 
active, the parser will attempt to stop processing the current 
packet and flush it's input Buffer. If however, parsing of the 
packet IS completed, the packet will not be able to be 

rf*pallf*H Thi^ chniilH nnlv he a nrnhlem in a 'cut through* 

implementation. 


DPReady.N 


OUT 


1 


DataPort Ready - active low. 

This signal when driven active means that the parser can 
accept new data. If however the parser's input Buffer is 
filled, DPReady_N will be driven inactive. To prevent 
overruns, DPReady_N will go inactive when the parser can 
actually accept one more data transfer. 


DPData 


IN 


32 


DataPort Data bus. 
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5.1.1.4 Host Interface Signals 



Signal 


Dir 


Width 


Description 


ParserSeLN 


IN 


1 


Parser Select - active low. 

ParserSeLN is sampled on the rising edge of MCLK. If it 
is active, it signifies that the external host is attempting to 
access the parser. 


HostWrite 


IN 


1 


Write. 

Write is sampled on the rising edge of MCLK. This signal 
is only valid when ParserSel _N is active. If this signal is 
active, the host is attempting to write to the parser. Inactive 
this signal sign signifies a read from the parser. 


HostBlast^N 


IN 


1 


Burst Last - active low. 

HostBlast_N is sampled on the rising edge of MCLK. 
HostBlast_N tells the parser that the current transfer is the 
last transfer in this burst. 


HostWait.N 


IN 


1 


Wail - active low. 

HostWait^N is sampled on the rising edge of MCLK. The 
host asserts HostWait_N when it wishes to slow transfers 

between itself and the parser. 


ParHostReady_N 


OUT 


1 


Parser to Host Ready - active low. 

ParHostReady^N should be sampled on the rising edge of 
MCLK. The parser returns ParHostReady_N when the 
current cycle is completed. For a write operation, 
ParHostReady_N means that the HostDataIn bus has been 
latched. For a read operation ParHostReady_N means that 
the requested data is on the ParHostDataOut bus and is 
valid. ParHostReady N is blocked by HostWait N. 


HostAddress 


IN 


13 


Host Address bus. 

HostAddress is sampled on the rising edge of MCLK if 
ParserSeLN is active. This bus defines the first address in 
this burst to access in the 64 Kilobyte address space of the 
Parser. See Section x.x.x for the Address Utilization Map. 


HostByteEn^N 


IN 

1 


O : 


nosi oyie t^naDie ous — Active low, 

HostWait_N is sampled on the rising edge of MCLK. 


HostDataIn 


IN 


64 


Host Data Input bus. ~ " * 
HostDataIn is sampled on the rising edge of MCLK if 
HostWrite is active and HostWait N is inactive. 


ParHostDataOut | OUT 


64 ~] 

j 

1 


ParserHost Data Output bus. 

ParHostDataOut should be sampled on the rising edge of 
MCLK. Data on this bus is valid during a read cycle when 
ParHostReady^N is active. 
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6 MeterFlow Accelerator Parser Module Top Level VHDL Entity 

entity PAR_TOP is 
Port 

( 



AnalyzerReady : In stdjogic; 
DPDataStb^N : In std.Iogic; 
DPData : In stdjogic^vector (31 downto 0); 
DPKillPkt^N : In stdjogic; 
DPPacketDelim : In std^logic; 
Host Address : In stdjogic^vector (13 downto 0); 
HostBlast^N : In stdjogic; 
o HostByteEn_N : In std_Iogic_vector (7 downto 0); 
HostDataIn : In std J ogic_ vector (63 downto 0); 
HostWait^N : In stdjogic; 
HostWrite : In stdjogic; 
MCLK : In stdjogic; 
ParserSeLN : In stdjogic; 
Reset_N : In stdjogic; 
DPReady_N : Out std_Iogic; 

ParHostDataOut : Out std^logic.vector (63 downto 0); 

ParHostReady_N : Out stdjogic; 

ParserDataAvail : Out std^logic; 

ParserData : Out std_logic_vector (63 downto 0); 



ParserKeyDelim : Out stdjogic 

); 

end PAR_TOP; 



7 MeterFlow Accelerator Parser Module Top Level Verilog 
Module 

module par_top( AnalyzerReady, DPData, DPDataStb, DPKillPkt.N, DPPacketDelim. DPReady.N, 
HostAddress, HostBlast_N, HostDataIn, HostWait^N, HostWrite, 
MCLK, ParHostDataOut, ParHostReady^N, ParserData, 
ParserDataAvail, ParserKeyDelim, ParserSeLN, Reset.N ); 

input AnalyzerReady; 

input [63:0] DPData; 

input DPDataStb, DPKillPkt^N, DPPacketDelim; 
output DPReady_N; 

input [12:0] HostAddress; 

input HostBlast_N; 

input [63:0] HostDataIn; 

input HostWait.N, HostWrite. MCLK; 
output [63:0] ParHostDataOut; 
output ParHostReady_N; 
output [63:0] ParserData; 
output ParserDataAvail, ParserKeyDelim; 

input ParserSeLN, Reset_N; 

wire [8:0] DPICAdd; 

wire [63:0] PIBuSlData; 
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wire [8:0] SIPBAdd; 

wire [63:0] PIBuPREData; 

wire [8:0] PREnPIBAdd; 

wire [29:0] CMCoSlData; 

wire [8:0] SlAdd; 

wire [3:0] PREnSlProtocol; 

wire [63:0] SlPOBData; 

wire [5:0] PREnSlCommand; 

wire [8:0] SlPOBAdd; 

wire [8:0] CMCoPRDAdd; 

wire [22:0] CMCoPRDData; 

wire [3:0] BaseOffset; 

wire [22:0] CMCoPREData; 

wire [8:0] PREAdd; 

wire [22:0] PRDData; 

wire [29:0] SlData; 

wire [8:0] CMCoSIDAdd; 

wire [8:0] AICPOBAdd; 

wire [29:0] SIDData; 

wire [29:0] CMCoSIDData; 

wire [8:0] AICoPOBAdd; 

wire [8:0] SlFlowKeySize; 

wire [8:0] SlPIBAdd; 
wire AICDone; 
wire CMCoSIDWr; 
wire CMCoPRDWr; 
wire PREnSlEn; 
wire SlWrStb; 
wire SlDone; 
wire PREDone; 
wire DPICWrStb; 
wire DPICDone; 
wire Parser En; 

AICIll ( .AICDone(AICDone), .AICoPOBAdd(AICoPOBAdd[8:0]), 

.AnalyzerReady(AnalyzerReady), .MCLK{MCLK), 
.ParserDataAvail(ParserDataAvail), .ParserEn(ParserEn), 
.ParserKeyDelim(ParserKeyDelim), .ReseLN(Reset_N), .SlDone(SlDone), 
.SIFlowKeySize(SlFiowKeySize[8:0]) ); 
PRE 110 ( .BaseOffset(BaseOffset[3:0]), .CMCoPREData(CMCoPREData[22:0]), 
.MCLK(MCLK), .ParserEn(ParserEn), .PIBuPREData(PIBuPREData[63:0]), 
.PREAdd(PREAdd[8:0]), .PREDone(PREDone). .PREnPIBAdd(PREnPIBAdd[8:0]), 
.PREnSiCommand(PREnSlCommand[5:0]), .PREnSlEn(PREnSlEn), 
.PREnSlProtocol(PREnSlProtocol[3:0]), .ResecN(Reset_N) ); 
DPICIl ( .DPDataStb(DPDataStb), .DPICAdd(DPICAdd[8:0]), .DPICDone(DPICDone), 
.DPICWrStb(DPICWrStb), .DPKillPkt_N(DPKillPkt^N), 
.DPPacketDelim(DPPacketDelim), .DPReady_N(DPReady^N), .MCLK(MCLK), 
.ParserEn(ParserEn), ,PREDone(PREDone), .Reset_N(Reset_N) ); 
Slicer 12 ( .CMCoSlData(CMCoSlData[29:0]), .MCLK(MCLK), .ParserEn(ParserEn), 

.PIBuSlData(PIBuSlData[63:0]), .PREDone(PREDone), 

.PREnSlCommand(PREnSlCommand[5:0]), .PREnSlEn(PREnSlEn), 

.PREnSlProtocoKPREnSlProtocol [3:0]), .ReseLN(ReseCN), 

.SlAdd(SlAdd[8:0]), .SlDone(SlDone), 

.SlFlowKeySize(SlFlowKeySize[8:0]), .SlPIBAdd(SlPIBAdd[8:0]), 
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.SlPOBAdd(SIPOBAdd[8:0]), .SIPOBData(SlPOBDatar63:0]) ' ' ~ ' 
.SlWrStb(SlWrStb) ); 

SID 13 ( .CMCoSIDAdd(CMCoSIDAdd[8:0]), .CMCoSIDData(CMCoSIDDatar29 01) 

.CMCoSIDWr(CMCoSIDWr), .SIDData(SIDData(29:0]) ); 
PRDI4 ( .CMCoPRDAdd(CMCoPRDAdd[8:0]), .CMCoPRDData(CMCoPRDData[22 01) 

.CMCoPRDWr(CMCoPRDWr), .PRDData(PRDData[22:0]) ); ' 
POB 15 ( .AICDone(AICDone), .AICoPOBAdd(AICoPOBAdd[8:0]), .MCLK(MCLK) 

.ParserData(ParserData[63:0]), .ParserEn(ParserEn), .Reset_N(Reset_N) 

.SlDone(SlDone),.SlPOBAdd(SlPOBAdd[8:0]), .SIPOBData(SlPOBData[63 01) 
.SlWrStb(SlWrStb) ); ' 

PIB 16 ( .DPData(DPData[63:0]), .DPICAdd(DPICAdd[8:0]), .DPICDone(DPICDone) 

.DPICWrStb(DPICWrStb), .MCLK(MCLK), .ParserEn(ParserEn), 

.PIBuPREData(PIBuPREData[63:0)), .PIBuSlData(ProuSlData[63:0]) 

.PREDone(PREDone), .PREnPIBAdd(PREnPIBAdd[8:0]), .Reset_N(Reset_N) 

.SlDone(SlDone), .SlPIBAdd(SIPBAdd[8:0]) ); 
CMC 18 ( .BaseOffset(BaseOffset[3:0]), .CMCoPRDAdd(CMCoPRDAdd[8-0]) 

.CMCoPRDData(CMCoPRDData[22:0]), .CMCoPRDWr(CMCoPRDWr). ' 

.CMCoPREData(CMCoPREData[22:0]), .CMCoSIDAdd(CMCoSIDAdd['8:0]) 

.CMCoSIDData(CMCoSIDData[8.0]), .CMCoSIDWr(CMCoSIDWr). 

.CMCoSlData(CMCoSlData[29:0]), .HostAddress(HostAddress[12:0]), 

.HostBlast_N(HostBlast_N), .HostDataIn(HostDataIn[63:0]), 

.HostWait_N(HostWait_N), .HostWrite(HostWrite), .MCLK(MCLK). 

.ParHostDataOut(ParHostDataOut[63:0]), 

.ParHostReady_N(ParHostReady_N), .ParserEn(ParscrEn), 

.ParserSeLN(ParserSel_N), .PRDData(PRDData[22:0]), 

,PREAdd(PREAdd(8:0]), .Reset_N(Reset_N), .SIDData(SlDatar29-01) 

.SIAdd(SlAdd[8:0]) ); 

endmodule // par_top 
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8 MeterFlow Accelerator Parser Module Top Level Schematic 

Insert Schematic Here 
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9 Parser Module Constants Files 



The parser module constants files contain a list of constants used to allow rapid configuration of tlie 
module. For example the size of the slicers instruction database data bus is defined as : 

Verilog 

'define PAR_SLI_DWIDTH 23 // Parser Slicer Instruction Database Data Bus Width 
VHDL 

constant PAR_SLI_DWIDTH : integer := 23; - Parser Slicer Instruction Database Data Bus Width 



9. 1 Parser module Verilog Constants File - ParserConstants. v 

'define PAR_COM_SHIFT 3 // Parser Command Shift 
'define PAR_SLI_DWIDTH 23 

'define PAR_DP_DWIDTH 32 // Parser Data Port Data Bus Width 

'define PAR_PIB_DWIDTH 64 // Parser Input Buffer Data Bus Width 

'define PAR_PIB_AWIDTH 9 // Parser Input Buffer Address Bus Width 

'define PAR_PRD_AWIDTH 9 // Parser Pattern Recognition Database Address Bus Width 

'define PAR_PRD_DWIDTH 23 // Parser Pattern Recognition Database Data Bus Width 

'define PAR_SID_AWIDTH 9 // Parser Slicer Instruction Database Address Bus Width 

'define PAR_SID_DWIDTH 30 // Parser Slicer Instruction Database Data Bus Width 

'define PAR_POB_DWIDTH 64 // Parser Output Buffer Data Bus Width 

'define PAR_POB_AWIDTH 9 // Parser Output Buffer Address Bus Width 

'define PAR_BASE_OFF_WIDTH 4 // Parser Base Offset Width 

'define PAR_HOST_AWIDTH 13 // Parser Host Address Bus Width 

'define PAR_HOST_BE_WIDTH 8 // Parser Host Byte Enable Bus Width 

'define PAR_HOST_DWIDTH 64 // Parser Host Data Bus Width 

'define PAR_PRE_COM_WIDTH 6 // Parser Command Width 

'define PAR_COM_CT_WIDTH 4 // Parser Command Count Width 

'define PAR_PRE_PRO_WIDTH 4 // Parser 

'define PAR_CONTROL_REG_SIZE 5 // Parser Control Register Size 

'define PAR_H_SIDDELTA 34 

'define PAR_H_PRDDELTA 41 

'define PAR_H_CRDELTA 59 // CANT BE NESTED! 

'define PAR_SL_FKS_WIDTH 9 // Parser Slicer Flow Key Size Width 

9.2 Parser module VHDL Constants File - ParserConstants.vhd 

Insert ParserConstants.vhd here 
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10 Sub-module Descriptions 



10. 1 Pattern Recognition Engine Sub-module - PRE 



10.1.1 Symbol 



10.1.2 Highlights 

• Scaleable protocol pattern recognition engine 

• Supports from 1 to 2048 simultaneous unique protocol patterns 

• At 62.5 MegaHertz can process up to 1 .5 MegaPackets per second 

• Accepts protocol database output from MeterFiow compiler 



10.1.3 Description 

The Pattern Recognition Engine module searches it's database and the packet in order to recognize the 
protocols the packet contains. The database consists of a series of linked lookup tables. Each lookup table 
uses eight bits of addressing. The first lookup table is always at address zero. The Pattern Recognition 
Engine uses the BaseOffset from the control register to start the comparison. It loads this value into the 
Current Offset Pointer (COP). It then reads the byte at BaseOffset from the Parser Input Buffer and uses 
It as an address into the first lookup table. 

Each lookup table returns a word that links to another lookup table or it returns a terminal flag If the 
lookup produces a recognition event the database also returns a command for the Slicer. Finally it returns 
the value to add to the COP. 



10.1.4 Search Algorithm Psuedo-code 

10.1.5 Implementation Information 



10.1.5.1 


Dat2 


ibase Word Definition 


Bit 


Description 


1:0 


Opcode 

GO Terminal Node found 

01 Intermediate Node 

10 Ending Terminal Node found 




Next Lookup table 

* uses PAR^PRE LU WIDTH 


* 


Slicer Command 

* uses PAR_PRE COM WIDTH 




Mask 

* uses PAR PRE MASK WIDTH 



10.1.6 File Names 



Top: PRE.v(hd) 
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Uses: ParserConstants.v(hd) 



10.1.7 Pin Descriptions 



10.1.7.1 General Interface Signals 


Signal 


Dir 


Width 


Description 


Reset_N 


IN 


1 


Reset - active low. 


MCLK 


IN 


1 


Module Clock. 


PREDone 


OUT 


1 


Pattern Recognition Engine Done. 


ParserEn 


IN 


1 


Parser Enable bit from control register 




10.1.7.2 Slice 


r Interface 


Signal 


Dir 


Width 


Description 


PREnSlEn 


OUT 


1 


Pattern Recognition Engine to Slicer Enable 


PREnSIConunand 


OUT 


* 


Pattern Recognition Engine to Slicer Command bus 
* uses PAR PRE COM WIDTH 


PREnSlProtocol 


OUT 


* 


Pattern Recognition Engine to Slicer Protocol bus 
* uses PAR PRE PRO WIDTH 




10.1.7.3 CPU Interface MUX Interface 


Signal 


Dir 


Width 


Description 


PREAdd 


OUT 


* 


Pattern Recognition Engine Address bus 
* uses PAR PRD AWIDTH 


BaseOffiset 


IN 


4 


Base Offset. 

This is the first offset the Pattern Recognition Engine will 
check. 


CMCoPREData 


IN 


* 


CMC to Pattern Rcognition Engine Data bus 
* uses PAR_PRD_DWIDTH 




10.1.7.4 Parser Input Buffer Interface 


Signal 


Dir 


Width 


Description 


PREnPIBAdd 


OUT 


* 


Pattern Recognition Engine Parser Input Buffer Address 
bus. 

* Uses PAR^PIB_A WIDTH 


PIBuPREData 


IN 




Parser Input Buffer to Pattern Recognition Engine Data bus. 
* Uses PAR_PIB .DWIDTH 



10.1.8 Verilog Module 



/* 

PRE.V 

PRE - Pattern Recognition Module 
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Mnclude TarserConstants.v" 

module PRE(ReseLN, MCLK ,ParserEn, PREDone, PREnSIEn, PREnSICommand, PREnSlProtocol 
PREAdd, BaseOffset, CMCoPREData, PREnPIBAdd, PIBuPREData); 

// General Interface Interface 

input Reset_N; 

input MCLK; 

input ParserEn; 

output PREDone; 

// Slicer Interface 

output PREnSIEn; 

output [TAR^PRE_C0M„WIDTH-1 : 0] PREnSICommand; 
output [TAR_PRE.PRO.WIDTH-l : 0] PREnSlProtocol; 
// CMC Interface 

output [TAR_PRD_AWIDTH-1 : 0] PREAdd; 
input [TARJASE_0FF_WIDTH-1 : 0] BaseOffset; 
input [TAR_PRD_DWIDTH-I : 0] CMCoPREData; 
// Parser Input Buffer Interface 
output [TAR,PIB_AWIDTH-1 : 0] PREnPIBAdd; 
input [TAR_PIB_DWIDTH-1 : 0] PIBuPREData; 
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10.2Slicer Sub-module 
10,2.1 Symbol 



10.2.2 Description 

The Slicer cuts up the packet to build the flow key. The Slicer module accepts commands from the Pattern 
Recognition Engine. Based on the command received, the Slicer either transfers data from the Parser 
Input Buffer to the Parser Output Buffer or it transfers data from the Parser Input Buffer to it's internal 
hash generator. It contains a buffer that FIFO's up the commands. When the Pattern Recognition Engine 
asserts PREDone the Slicer completes any pending commands, transfers the hash to the Parser Output 
Buffer and asserts SlDone. 



10.2.2.1 Instruction Word Definition 


Bit 


Description 


1:0 


Opcode 

00 Nop 

01 Move 

10 Hash 

1 1 Done 




Source Address 

* uses PAR^PIB.AWIDTH 




Destination Address 

* uses PAR_POB_AWIDTH 


* 


Length 

* uses PAR_SL„LEN_WIDTH 



10.2.3 Implementation Information 

The Slicer contains a byte wise barrel shifter that is used to pack data into the flow key. A Moore finite 

state machine controls the execution of commands. The command comes into the Slicer and is shifted to 
provide an address. The Slicer uses this address to read the Slicer Instruction Database. 

10.2.4 File Names 

Top: Slicer. v(hd) 

Uses: ParserConstants.v(hd) 
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10.2.5 Pin Descriptions 



10.2.5.1 Gen 


era! Interface Signals 


Signal 


Dir 


Width 


Description 


Reset_N 


IN 


1 


Reset - active low. 


MCLK 


IN 


1 


Module Clock. 


SIDone 


OUT 


1 


Slicer Done. 

This output is used to tell the rest of the Parser that the 
Slicer has finished processing the current packet. 


ParserEn 


IN 


1 


Parser Enable bit from control register 




10.2.5.2 Parser Input Buffer Interface 


Signal 


Dir 


Width 


Description 


SIPIBAdd 


OUT 


* 


Slicer Parser Input Buffer Address bus. 
* Uses PAR PIB AWIDTH 


PIBuSIData 


IN 


* 


Parser Input Buffer to Slicer Data bus. 
* Uses PAR PIB DWIDTH 




10.2.5.3 Parser Output Buffer Interface 


Signal 


Dir 


Width 


Description 


SIPOBAdd 


OUT 


* 


Slicer Parser Output Buffer Address bus. 
* Uses PAR POB AWIDTH 


SlWrStb 


OUT 


1 


Slicer Write Strobe. 


SlPOBData 


OUT 


* 


Slicer to Parser Output Buffer Data bus. 
* Uses PAR POB DWIDTH 




10.2.5.4 CPU Interface MUX Interface 


Signal 


Dir 


Width 


Description 


SiAdd 


OUT 




Slicer Address bus 

* uses PAR_SID_A WIDTH 


CMCoSlData 


IN 


* 


CMC to Slicer Data bus 
* uses PAR^SID^DWIDTH 




10.2.5.5 Pattern Recognition Engine Interface 


Signal 


Dir 


Width 


Description 


PREnSlEn 


IN 


1 


Pattern Recognition Engine to Slicer Enable 


PREDone 


IN 


1 


Pattern Recognition Engine Done. 


PREnSlCommand 


IN 


* 


Pattern Recognition Engine to Slicer Command bus 
* uses PAR_PRE^COM_WIDTH 


PREnSlProtocol 


IN 


* 


Pattern Recognition Engine to Slicer Protocol bus 
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10.2.5.6 



Analyzer Interface Control Interface 



Signal 



Dir 



Width 



Description 



SlFIowKeySize 



OUT 



Pattern Recognition Engine to Slicer Protocol bus 
* uses PAR^SLJKS^WIDTH 



10.2.6 Verilog Module 

/* 

Slicer.v 
Slicer Module 



*/ 

'include "ParserConstants.v" 

module Slicer(Reset„N, MCLK ,ParserEn, SlDone, SlPIBAdd, PIBuSlData, SlPOBAdd, SiWrStb, 
SlPOBData, SlAdd, CMCoSlData, PREnSlEn, PREDone, PREnSlCommand, PREnSlProtocol 
SlFIowKeySize); 

// General Interface Interface 
input Reset_N; 
input MCLK; 
input ParserEn; 
output SlDone; 

// Parser Input Buffer Interface 

output [TAR_PIB_AWIDTH-1 : 0] SlPIBAdd; 

input [TAR„PIB_D WIDTH- 1 : 0] PIBuSlData; 

// Parser Output Buffer Interface 

output [TAR_P0B_AWIDTH-1 : 0] SIPOBAdd; 

output SlWrStb; 

output [TAR_POB_DWIDTH-] : 0] SlPOBData; 
// CMC Interface 

output [TAR^SID_A WIDTH- 1 : 0] SlAdd; 
output [TAR_SID_DWIDTH-1 : 0] CMCoSlData; 
// Pattern Recognition Engine Interface 
input PREnSlEn; 
input PREDone; 

input [TAR^PRE_C0M_WIDTH-1 : 0] PREnSlCommand; 
input [TAR_PRE^PR0_WIDTH-1 : 0] PREnSlProtocol; 
//AIC 

output [TAR_SL.FKS^WIDTH-1 : 0] SlFIowKeySize; 
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10.3 Pattern Recognition Database Sub-module - PRO 

10.3.1 Symbol 



10.3.2 Highlights 

• Scaleable implementation 

• Wraps either RAM or ROM instantiation or can be synthesized latches 

10.3.3 Description 

The Pattern Recognition Database Memory module is a wrapper for the storage medium used to hold the 
pattern recognition database. Only the CPU can write this memory. 

10.3.4 Implementation Information 

The module can be synthesized or a RAM or ROM cell can be instantiated into the wrapper, 

10.3.5 File Names 
Top: PRD.v(hd) 

Uses: ParserConstants.v(hd),GenericRAM.v(hd) 



10.3.6 Pin Descriptions 



10.3.6.1 CPU Interface MUX Interface 


Signal 


Dir 


Width 


Description 


CMCoPRDWr 


IN 


1 


CMC to PRD Write Strobe 


CMCoPRDAdd 


IN 


* 


CMC to PRD Address bus 
* uses PAR_PRD_AWIDTH 


PRDData 


OUT 




PRD Data bus 

* uses PAR^PRD^DWIDTH 


CMCoPRDData 


IN 


* 


CMC to PRD Data bus 

* uses PAR.PRD^DWIDTH 



10.3.7 Verilog Module 



/* 

PRD.v 

*/ 

'include "ParserConstants.v" 

module PRD{CMCoPRDData, PRDData, CMCoPRDAdd, CMCoPRDWr); 

input [TAR_PRD_A WIDTH- 1 : 0] CMCoPRDAdd; 
input [TAR_PRD_D WIDTH- 1 : 0] CMCoPRDData; 
output [TAR^PRD^DWIDTH-I : 0] PRDData; 
input CMCoPRDWr; 
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10.4 Slicer Instruction Database Sub-module -SID 

10.4.1 Symbol 

10.4.2 Highlights 

• Scaleable implementation 

• Wraps either RAM or ROM instantiation or can be synthesized latches 

10.4.3 Description 

The Slicer Instruction Database module is a wrapper for the storage medium used to hold the pattern 
recognition database. Only the CPU can write this memory. 

10.4.4 Implementation Information 

The module can be synthesized or a RAM or ROM cell can be instantiated into the wrapper. 

10.4.5 File Names 
Top: SID.v(hd) 

Uses: ParserConstants.v(hd),GenericRAM.v(hd) 



10.4.6 Pin Descriptions 



10.4.6.1 CPU 


Interface MUX Interface 


Signal 


Dir 


Width 


Description 


CMCoSIDWr 


IN 


1 


CMC to SID Write Strobe 


CMCoSIDAdd 


IN 


* 


CMC to SID Address bus 
* uses PAR SID AWIDTH 


SIDData 


OUT 


* 


SID Data bus 

* uses PAR_SID_DWIDTH 


CMCoSIDData 


IN 




CMC to SID Data bus 

* uses PAR SID DWIDTH 



10.4.7 Verilog Module 



/* 

SID.v 

*/ 

Mnclude "ParserConstants.v" 

module SID(CMCoSIDData. SIDData, CMCoSIDAdd, CMCoSIDWr); 

input [TAR_SID_A WIDTH- 1 : 0] CMCoSIDAdd; 
input [TAR_SID_DWIDTH-1 : 0] CMCoSIDData; 
output [TAR_SID_D WIDTH- 1 : 0] SIDData; 
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10.5 CPU Interface MUX and Control Register Sub-module - CMC 

10.5.1 Symbol 



10.5.2 Description 

The CPU Interface MUX and Control Register module controls the communication between the external 
CPU and the Parser. The CMC contains a MUX for the CPU read back. It also contains the control 
register for the Parser. 

10.5.3 File Names 

Top: CMC.v(hd) 

Uses: ParserConstants.v(hd) 



10.5.4 Pin Descriptions 



10.5.4.1 Gen 


eral Interface Signals 


Signal 


Dir 


Width 


Description 


Reset N 


IN 


1 


Reset - active low. 


MCLK 


IN 


1 


Module Clock. 


ParserEn 


OUT 


1 


Parser Enable bit from control register. 
When this bit becomes active 




10.5.4.2 Slice 


r Instruction Database Interface 


Signal 


Dir 


Width 


Description 


CMCoSIDWr 


OUT 


1 


CMC to SID Write Strobe 


CMCoSroAdd 


OUT 


* 


CMC to SID Address bus 
* uses PAR^SID^A WIDTH 


SIDData 


IN 




SID Data bus 

* uses PAR_SID_DWIDTH 


CMCoSIDData 


OUT 


* 


CMC to SID Data bus 

* uses PAR SID DWIDTH 



10.5.4.3 Pattern Recognition Database Interface 


Signal 


Dir 


Width 


Description 


CMCoPRDWr 


OUT 


1 


CMC to PRD Write Strobe 


CMCoPRDAdd 


OUT 


* 


CMC to PRD Address bus 
* uses PAR PRD AWIDTH 


PRDData 


IN 


* 


PRD Data bus 

* uses PAR_PRD DWIDTH 


CMCoPRDData 


OUT 


* 


CMC to PRD Data bus 

* uses PAR PRD DWIDTH 
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10.5.4.4 SUc( 


:r Interface 


Signal 


Dir 


Width 


Description 


SiAdd 


IN 


* 


Slicer Address bus 

* uses PAR__SID_A WIDTH 


COCoSiData 


OUT 


* 


CMC to Slicer Data bus 
* uses PAR SID DWIDTH 




10.5.4.5 PatU 


irn Reco 


gnition Engine Interface 


Signal 


Dir 


Width 


Description 


PREAdd 


IN 


* 


Pattern Recognition Engine Address bus 
* uses PAR PRD AWIDTH 


BaseOffset 


OUT 


4 


Base Offset. 

This is the first offset the Pattern Recognition Engine will 
check. 


CMCoPREOata 


OUT 


* 


CMC to Pattern Rcognition Engine Data bus 
* uses PAR PRD DWIDTH 



10.5.4.6 Host Interface Signals 


Signal 


Dir 


Width 


Description 


ParserSeLN 


IN 


1 


Parser Select - active low. 

ParserSeLN is sampled on the rising edge of MCLK. If it 
is active, it signifies that the external host is attempting to 
access the parser. 


HostWrite 


IN 


1 


Write. 

Write is sampled on the rising edge of MCLK. This signal 
is only valid when ParserSel _N is active. If this signal is 
active, the host is attempting to write to the parser. Inactive 
this signal sign signifies a read from the parser. 


HostBlast.N 


IN 


1 


Burst Last - active low. 

HostBlast_N is sampled on the rising edge of MCLK. 
HostBIast__N tells the parser that the current transfer is the 
last transfer in this burst. 


HostWait^N 


IN 


1 


Wait - active low. 

HostWait^N is sampled on the rising edge of MCLK. The 
host asserts HostWait_N when it wishes to slow transfers 
between itself and the parser. 


ParHostReady^N 


OUT 


1 


Parser to Host Ready - active low. 
ParHostReady_N should be sampled on the rising edge of 
MCLK. The parser returns ParHostReady_N when the 
current cycle is completed. For a write operation, 
ParHostReady^N means that the HostDataIn bus has been 
latched. For a read operation ParHostReady_N means that 
the requested data is on the ParHostDataOut bus and is 
valid. ParHostReady N is blocked by HostWait N. 



Confidential 



Technically Elite MeterFlow Accelerator Parser Module Specification 

Page 29 of 44 



Technic ally Elit e CONFroENTIAL 



HostAddress 


IN 


13 


Host Address bus. 

HostAddress is sampled on the rising edge of MCLK if 
ParserSeLN is active. This bus defines the first address in 
this burst to access in the 64 Kilobyte address space of the 
Parser. See Section x.x.x for the Address ytilization Map. 


HostByteEn.N 


IN 


8 


Host Byte Enable bus - Active low. 

HostWait_N is sampled on the rising edge of MCLK. 


HostDataIn 


IN 


64 


Host Data Input bus. 

HostDataIn is sampled on the rising edge of MCLK if 
HostWnte is active and HostWait_N is inactive. 


ParHostDataOut 


bur" 


64 


ParserHost Data Output bus. 

ParHostDataOut should be sampled on the rising edge of 
MCLK. Data on this bus is valid during a read cycle when 
ParHostReady„N is active. 



10«5.5 Verilog Module 



/* 

CMC.v 

CMC - CPU Interface MUX and Control Register Module 



*/ 

'include "ParserConstants.v" 



module CMC(Reset_N, MCLK ,ParserEn, CMCoSIDWr, CMCoSIDAdd, SIDData, CMCoSIDData, 
CMCoPRDWr, CMCoPRDAdd, PRDData, CMCoPRDData, SlAdd, CMCoSlData, PREAdd, BaseOffset, 
CMCoPREData, ParserSeLN, HostWrite, HostBlast.N, HostWait.N, ParHostReady_N, HostAddress, 
HostDataIn, ParHostDataOut); 



// General Interface Interface 
input Reset_N; 
input MCLK; 
output ParserEn; 

// Sicer Instruction Database Interface 
output CMCoSIDWr; 

output rPAR_SID^A WIDTH- 1 : 0] CMCoSIDAdd; 
input [TAR„SID_DWIDmi : 0] SIDData; 
output [^PAR„SID_A WIDTH- 1 : 0) CMCoSIDData; 
// Pattern Recognition Database Interface 
output CMCoPRDWr; 

output [TAR_PRD_AWIDTH-l : 0] CMCoPRDAdd; 
input rPAR^PRD_D WIDTH- 1 : 0] PRDData; 
output [T AR.PRD_D WIDTH- 1 : 0] CMCoPRDData; 
// Slicer Interface 

input rPAR_,SID_AWIDTH-l : 0] SlAdd; 
output [T AR_SID_D WIDTH- 1 : 0] CMCoSlData; 
// Pattern Recognition Engine Interface 
input rPAR_PRD„AWIDTH-l : 0] PREAdd; 
output [ PAR_BASE_0FF_WIDTH-1 : 0] BaseOffset; 
output [ PAR^PRD_DWIDTH.l : 0] CMCoPREData; 
//Host Interface 
input ParserSeLN; 
input HostWrite; 
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input HostBlast^N; 

input HostWait_N; 
output ParHostReady_N; 

input [TAR^HOST^AWIDTH-I : 0] HostAddress; 
input [TAR^HOST^DWIDTH-1 : 0] HostDataIn; 
output [TAR^H0ST„DWIDTH-1 : 0] ParHostDataOut; 
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10.6 Parser Input Buffer Sub-module - PIB 



10.6.1 Symbol 



!:'Fu::A»iei;<v;0| 




10.6.2 Highlights 

• Scaleable implementation 

• Asynchronous three ported RAM 

• Can be build from three separate single port RAM cells 

• Wraps either RAM instantiation or can be synthesized latches 

• Separate dual read and a single write interfaces 

10.6.3 Description 

The Parser Input Buffer is a wrapper for the buffer that is used to store the start of the packet. It is three 
ported with separate dual read and a single write interfaces. The data from the DataPort interface is stored 
in one of three logical or physical buffers through the write port. The Pattern Recognition Engine uses one 
of the read ports and the Slicer uses the other. The three interfaces never access the same third of the 
buffer at the same time. Each of the interfaces looks like a single buffer to the attached modules. The 
Parser Input Buffer controls which of the three buffers the module is controlling. When the first packet 
comes in the DataPort Interface Control module writes the data into one of the three buffers. It then 
increments a modulo three counter to point to the next buffer. The Pattern Recognition Engine will then 
begin processing the packet. Finally after the Pattern Recognition Engine is finished the Slicer will get 
access to the buffer. In this way each of the three processes have access to a buffer and each get access to 
the packet in turn. 

10.6.4 Implementation Information 

The module can be synthesized or RAM cells can be instantiated into the wrapper. The instantiated RAM 
can be either a single three ported cell or three separate RAM cells. The Parser Input Buffer can be three 
separate RAM cells because the control logic will never try to read and write the same third of the buffer 
at the same time. 
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10.6.5 File Names 
Top: PIB.v(hd) 

Uses: ParserConstants.v(hd), Generic3PortRAM.v(hd) 

10.6.6 Pin Descriptions 



10.6.6.1 General Interface Signals 


Signal 


Dir 


Width 


Description 


Reset N 


IN 


1 


Reset - active low. 


MCLK 


IN 


1 


Module Clock. 


ParserEn 


IN 


1 


Parser Enable bit from control register 



10.6.6.2 DataPort Interface 


Signal 


Dir 


Width 


Description 


DPData 


IN 




DataPort Data bus. 

* Uses PAR DP_DWIDTH 




10.6.6.3 DataPort Interface Control Interface 


Signal 


Dir 


Width 


Description 


DPICAdd 


IN 




DataPort Interface Control Address bus. 
* Uses PAR PIB AWIDTH 


DPICDone 


IN 


1 


DataPort Interface Control Done. 
This input is used to tell the Parser Input Buffer that the 
DataPort Interface Control module has finished writing the 
buffer. The Parser Input Buffer also uses this signal to 
increment it*s internal pointer so that the next address from 
the DataPort Interface Control will point to the next packet 
buffer. DPICAdd is ignored for one cycle after DPICDone 
is active. 


DPICWriteStb 


IN 


1 


DataPort Interface Control Write Strobe. 



10.6.6.4 Pattern Recognition Engine Interface 


Signal 


Dir 


Width 


Description 


PREnPIBAdd 


IN 


* 


Pattern Recognition Engine Parser Input Buffer Address 

bus. 

* Uses PAR^PIB^AWIDTH 
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10.6.6.4 Pattern Recognition Engine Interface 


Signal 


Dir 


Width 


Description 


PREDone 


IN 


1 


Pattern Rpropnifinn Pnoinp F^nnf 
This input is used to tell the Parser Input Buffer that the 
Pattern Recognition Engine has finished processing the 
current packet and the buffer can be freed. The Parser Input 
Buffer also uses this signal to increment it's internal pointer 
so that the next address from the Pattern Recognition 
Engine will point to the next packet buffer. PREnPIBAdd 
is ignored for one cycle after PREDone is active. 


PIBuPREData 


OUT 


* 


Parser Input Buffer to Pattern Recognition Engine Data bus. 
* Uses PAR^PIB _DWIDTH 



10.6.6.5 Slicer Interface 


Signal 


Dir 


Width 


Description 


SlPIBAdd 


IN 


* 


Slicer Parser Input Buffer Address bus. 
* Uses PAR^PIB^AWIDTH 


SlDone 


IN 


I 


Slicer Done. 

This input is used to tell the Parser Input Buffer that the 
Slicer has finished processing the current packet and the 
buffer can be freed. The Parser Input Buffer also uses this 
signal to increment it's internal pointer so that the next 
address from the Slicer will point to the next packet buffer. 
SlPIBAdd is ignored for one cycle after SlDone is active. 


PIBuSIData 


OUT 


* 


Parser Input Buffer to Slicer Data bus. 
* Uses PAR_PIB_DWIDTH 



10.6.7 Verilog Module 



/* 

PIB.v 



*/ 

'include "ParserConstants.v" 

module PIB(Reset_.N, MCLK ,ParserEn, DPData, DPICAdd, DPICDone, DPICWrStb, PREnPIBAdd, 
PREDone, PIBuPREData, SlPIBAdd, SlDone, PIBuSIData); 

input Reset_N; 
input MCLK; 
input ParserEn; 
input DPICDone; 
input DPICWrStb; 
input PREDone; 
input SlDone; 

input [TAR^PIB^DWIDTH-l : 0] DPData; 
input PPAR.PIB^A WIDTH- 1 : 0] DPICAdd; 
input rPAR_PIB„AWIDTH.l : 0] PREnPIBAdd; 
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input [TAR_PIB„A WIDTH- 1 : 0] SlPIBAdd; 
output [TAR_PIB^DWIDTH-1 : 0] PIBuPREData; 
output [TAR^PIB^DWlDTH-l : 0] PIBuSlData; 



i 
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10.7 Parser Output Buffer Sub-module - POB 

10.7.1 Symbol 



10.7.2 Highlights 

• Scaleable implementation 

• Asynchronous dual ported RAM 

• Can be build from two separate single port RAM cells 

• Wraps either RAM instantiation or can be synthesized latches 

• Separate read and write interfaces 

10.7.3 Description 

The Parser Output Buffer is a wrapper for the buffer that is used to store the output of the Slicer. It is dual 
ported with separate read and write interfaces. The write interface is controlled by the Slicer. The read 
interface is controlled by the Analyzer Interface Control logic. The Parser Output Buffer maintains a 
pointer to the two buffers such that one buffer is controled by the Slicer and one is controlled by the 
Analyzer Interface Control logic. 

10.7.4 Implementation Information 

The module can be synthesized or RAM cells can be instantiated into the wrapper. The instantiated RAM 

can be either a single dual ported cell or two separate RAM cells. The Parser Output Buffer can be two 
separate RAM cells because the control logic will never try to read and write the same half of the buffer at 
the same time. 

10.7.5 File Names 



Top: POB.v(hd) 

Uses: ParserConstants.v(hd), Generic2PortRAM.v(hd) 
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10.7.6 Pin Descriptions 



10.7.6.1 General Interface Signals 


Signal 


Dir 


Width 


Description 


Reset^N 


IN 


1 


Reset - active low. 


MCLK 


IN 


1 


Module Clock. 


ParserEn 


IN 


1 


Parser Enable bit from control register 



10.7.6.2 Slicer Interface 


Signal 


Dir 


Width 


Description 


SlPOBAdd 


IN 


* 


Slicer Parser Output Buffer Address bus. 
* Uses PAR POB AWIDTH 


SIDone 


IN 


1 


Slicer Done. 

This input is used to tell the Parser Output Buffer that the 
Slicer has finished processing the current flow and the 
buffer can be sent to the Analyzer. The Parser Output Buffer 
also uses this signal to increment it*s internal pointer so that 
the next address from the Slicer will point to the next flow 
buffer. SlPOBAdd is ignored for one cycle after SIDone is 
active. 


SlWrStb 


IN 


1 


Slicer Write Strobe. 


SlPOBData 


IN 


* 


Slicer to Parser Output Buffer Data bus. 
* Uses PAR_POB_DWIDTH 



10.7.6.3 Analyzer Interface Control Interface 


Signal 


Dir 


Width 


Description 


AICoPOBAdd 


IN 




Analyzer Interface Control to Parser Output Buffer Address 
bus. 

* Uses PAR_POB^AWIDTH 


AICDone 


IN 


1 


Analyzer Interface Control Done. 
This input is used to tell the Parser Output Buffer that the 
Analyzer Interface Control has finished sending the current 
flow to the Analyzer. The Parser Output Buffer also uses 
this signal to increment it*s internal pointer so that the next 
address from the Analyzer Interface Control will point to the 
next flow buffer. AICoPOBAdd is ignored for one cycle 
after AICDone is active. 




10.7.6.4 Analyzer Interface 


Signal 


Dir 


Width 


Description 


ParserData 


OUT 


# 


Parser Data bus. 

* Uses PAR ANA.D WIDTH 
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10 J.7 Verilog Module 

/* 

POB.v 



*/ 

'include "ParserConstants.v" 

module POB(Reset_N, MCLK .ParserEn, SlPOBData, SlPOBAdd, SIDone, SlWrStb, 

AICoPOBAdd, AICDone, ParserData); 

input Reset_N; 
input MCLK; 
input ParserEn; 
input SlDone; 
input SlWrStb; 
input AICDone; 

input [TAR_POB^DWIDTH.l : 0] SlPOBData; 
input [TAR_P0B_AWIDTH-1 : 0] SlPOBAdd; 
input [TAR_P0B_AWIDTH-1 : 0] AICoPOBAdd; 
output [TAR^POB.D WIDTH- 1 : 0] ParserData; 



Confidential 



Technically Elite MeterFlow Accelerator Parser Module Specification 

Page 38 of 44 




Technically Elite CONFIDENTIAL 



10.8DataPort Interface Control Sub-module - DPIC 

10.8.1 Symbol 



10.8.2 Description 

The DataPort Interface Control module handshakes with the external source of packets. The external 
device starts sending the packet to the DataPort Interface Control module by asserting DPPacketDelim. 
The transfer of data is coordinated by the DPDataStb_N/DPReady_N pair. If the external device decides 
to about the packet it can assert DPKillPkt.N. 

10.8.3 Implementation Information 

The Analyzer Interface Control module is implemented as a Moore type finite state machine. Each of the 
outputs of the state machine are registered to assure maximum setup time for the external device. 

10.8.4 File Names 

Top: DPIC.v(hd) 

Uses: ParserConstants.v(hd) 



10.8.5 Pin Descriptions 



10.8.5.1 General Interface Signals 


Signal 


Dir 


Width 


Description 


Reset_N 


IN 


1 


Reset - active low. 


MCLK 


IN 


1 


Module Clock. 


ParserEn 


IN 


1 


Parser Enable bit from control register 



10.8.5.2 DataPort Interface 


Signal 


Dir 


Width 


Description 


DPPacketDelim 


IN 


1 


DataPort Packet Delimiter. 

This signal should be driven active when the external logic 
wants to send a packet to the parser. DPPacketDelim 
should remain active during the entire packet transfer. 
DPPacketDelim must go inactive for one clock between 
packets. 


DPDataStb.N 


IN 


1 


DataPort Data Strobe. 

When active, this signal tells the parser that data on the 
DPData bus is valid. If DPReady^N was inactive at the end 
of the previous cycle, DPDataStb^N should not be driven 
active. If DPReady^N goes inactive in the same cycle as 
DPDataStb^N, then the parser will latch the incoming data 
so that no data is lost. 
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10.8.5.2 DataPort Interface 


Signal 


Dir 


Width 


Description 


DPKiilPkt_N 


IN 


1 


DataPort Kill Packet. 

If this signal becomes active while DPPacketDelim is 
active, the parser will attempt to stop processing the current 
packet and flush it's input Buffer. If however, parsing of the 
packet is completed, the packet will not be able to be 
recalled. This should only be a problem in a *cut through' 
implementation. 


DPReady_N 


OUT 


1 


DataPort Ready - active low. 

This signal when driven active means that the parser can 
accept new data. If however the parser's input Buffer is 
filled, DPReady_N will be driven inactive. To prevent 
overruns, DPReady_N will go inactive when the parser can 
actually accept one more data transfer. 




10.8.5.3 Parser Input Buffer Interface 


Signal 


Dir 


Width 


Description 


DPICAdd 


OUT 




DataPort Interface Control Address bus. 
* Uses PAR_PIB_A WIDTH 


DPICDone 


OUT 


1 


DataPort Interface Control Done. 

This output is used to tell the Parser Input Buffer that the 

DataPort Interface Control module has finished writing the 

buffer. 


DPICWriteStb 


OUT 


1 


DataPort Interface Control Write Strobe. 




10.8.5.4 Pattern Recognition Engine Interface 


Signal 


Dir 


Width 


Description 


PREDone 


IN 




Pattern Recognition Engine Done 



10.8.6 Verilog Module 



/* 

DPIC.v 



'include "ParserConstants.v" 

module DPIC(Reset.N» MCLK ,ParserEn, DPPacketDelim, DPDataStb, DPKillPkt_N, DPReady^N, 
DPICAdd, DPICDone, DPICWrStb, PREDone); 

input Reset_N; 
input MCLK; 
input ParserEn; 
input DPPacketDelim; 
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input DPDataStb; 
input DPKillPkt.N; 
input PREDone; 
output DPReady_N; 
output DPICDone; 
output DPICWrStb; 

output [TAR^PIB_AWIDTH-1 : 0] DPICAdd; 
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10.9 Analyzer Interface Control Sub-module -AlC 

m9A Symbol 



10.9.2 Description 

The Analyzer Interface Control module handshakes with the Analyzer in order to transfer the flow key for 
further processing. The Analyzer Interface Control module starts a transfer to the Analyzer by asserting 
ParserKeyDelim. It then transfers the data via the AnalyzerReady/ParserDataAvaii handshake pair. 
The Analyzer Interface Control module also sends the address of the data to be sent to the Parser Output 
Buffer. 

10.9.3 Implementation Information 

The Analyzer Interface Control module is implemented as a Moore type fmite state machine. Each of the 
outputs of the state machine are registered to assure maximum setup time for the Analyzer interface. 

10.9.4 File Names 

Top: AlC.v(hd) 

Uses: ParserConstants.v(hd) 



10.9.5 Pin Descriptions 



10.9.5.1 General Interface Signals 


Signal 


Dir 


Width 


Description 


Reset_N 


IN 


1 


Reset - active low. 


MCLK 


IN 


1 


Module Clock. 


ParserEn 


IN 


1 


Parser Enable bit from control register 



10.9.5.2 Analyzer Interface 


Signal 


Dir 


Width 


Description 


AnalyzerReady 


IN 


1 


Analyzer Ready. 

This signal tells the parser that the analyzer can accept data. 


ParserKeyDelim 


OUT 


1 


Parser Key Delimiter. 

The ParserKeyDelim signal becomes active when the first 
quadword of a new key is ready to transfer to the analyzer. It 
goes inactive when the last quadword of the key is 
transferred. 


ParserDataAvail 


OUT 


1 


Parser Data Available. 

If this signal is active the data on the ParserData bus is 
valid. 
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10.9.5.3 Slicer Interface 


Signal 


Dir 


Width 


Description 


SIFIowKeySize 


IN 


* 


Slicer Flow Key Size bus. 

This bus is valid when SIDone is active. It communicates 
the size of the flow key so the Analyzer Interface Control 
can send the right amount of data to the Analyzer. 
* uses PAR.MAX_FLOW_KEY„SIZE 


SIDone 


IN 


1 


Slicer Done. 

This input is used to tell the Analyzer Interface Control that 
the Slicer has finished processing the current packet and can 

be sent to the Analyzer. 



10.9.5.4 Parser Output Buffer Interface 


Signal 


Dir 


Width 


Description 


AICoPOBAdd 


OUT 


* 


Analyzer Interface Control to Parser Output Buffer Address 
bus. 

* Uses PAR POB AWIDTH 


AICDone 


OUT 


1 


Analyzer Interface Control Done. 

This output is used to tell the Parser Output Buffer that the 
Analyzer Interface Control has finished sending the current . 
flow to the Analyzer. 



10.9.6 Verilog Module 



/* 

AIC.v 



*/ 

'include "ParserConstants.v" 

module AIC(Reset_N, MCLK ,ParserEn, AnalyzerReady, ParserKeyDelim, ParserDataAvail, 
SIFIowKeySize, SIDone, AICoPOBAdd,AICDone); 

input Reset_N; 
input MCLK; 
input ParserEn; 
input AnalyzerReady; 
output ParserKeyDelim; 
output ParserDataAvail; 
input SIDone; 

input [TAR_SL_FKS_WIDTH-l : 0]SlFlowKeySize; 
output [TAR^PIB_AWIDTH-1 : 0] AICoPOBAdd; 
output AICDone; 

i 
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• Exhibit A3: Technically Elite MeterFlow Accelerator Analyzer Module 
Specification (Document MFAAnalyze.pdf) 
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1 Introduction 

This document is designed to be the repository for all information related to the MeterFlow Accelerator 
Analyzer Module. This specification is designed to provide the engineer with enough information to fully 
implement the module. There will be revisions during and after the implementation process that will be 
reflected in this document 

Each part of this specification describes a different aspect of the module. It concentrates on the interfaces 
between the analyzer module and the other parts of the system. The other parts of the system include the 
parser module, the host interface module and importantly the software that models, programs and tests the 
system The key to a successful implementation is the interfaces between modules and between sub-module 
and sub-module. Each interface is described in detail. Any changes to the interfaces may affect the entire 
module and even the entire system. Care must be taken that each interface is understood completely before 
implementation is begun. 



2 Technically Elite MeterFlow Accelerator Analyzer Module 
Highlights 

• Flexible Rule-based Traffic Classification 

• State-based Tracking of Traffic 

• Multiple Packets for Layer Processing 

• Internal Cache and Memory Controller 

• Direct High Bandwidth (64 bit) Memory Interface 

• SG/SDRAM Support 

• Programmable Rules/State Processor 

• Selectable Protocols in Flows 

• Future Protocols Support 

• Scalable System Design 
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3 Architectural Overview 

The analyzer module consists five major sub-modules with several supporting sub-modules. The major sub- 
modules are the flow lookup/update engine, the flow insertion and deletion engine, the state processor, the 
cache, and the unified memory controller. Each of these sub-modules work in parallel to create and update 
flows. 

As a flow key enters the analyzer, the lookup engine attempts to find it in the flow database. If the flow 
exists, the lookup engine retrieves the flow from the cache. It then makes a decision based on the state 
information included in the flow entry to either send it to the state processor or not. In either case it updates 
the flow entry. This updating consists of adding values to counters in the flow database entry. If a flow does 
not exist, the state processor sends the flow key to the flow insertion and deletion engine which adds the 
flow to the database. 

The state processor updates the flow based on the current state and the flow key information. The state 

processor processes single and multi packet protocol recognition. It may have to search through a series of 
possible states to determine the flow's actual state. The result of the state processor's processing is a 
consolidated flow entry. For example, a PointCast session will open multiple conversations that on a packet 
by packet basis look like separate flows. Since each conversation is merely a subflow under the PointCast 
master flow, a single flow that consolidates all of the information for the flow is desired. 

The unified memory controller can be setup to work with various configurations of SDRAM or SGRAM. It 
also controls the SRAM tag memory for shadowing of flow entries. 

The cache is used to optimize memory bandwidth. On a typical network the packets will have a certain 
amount of congruity. This means that the cache can have a high hit rate with . 
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3.1 Flow Database 

The Flow Database consists of a series of 128 byte entries. Each entry completely describes a flow. The 
format and information contained in the flow is described in section xxx. The database is organized into 
buckets. Each bucket contains n flow entries. N is determined by the designer. Buckets are accessed via a 
hash value created by the Parser based on information in the packet. This hash spreads the flows across the 
database and is based on a proprietary Technically Elite algorithm. This method allows fast look up of an 
entry while allowing for shallower buckets. The designer selects the bucket depth based on the amount of 
memory attached to the analyzer and the number of bits of the hash value used. For example, for 128k flow 
entries 16 Megabytes are required. Using a 16 bit hash gives two entries per bucket. This has been 
empirically shown to be more than adequate for the vast majority of cases. 
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3.1.1 Extracted Input Data from Parser Diagram 



Group ID-1 (2) 



Group ID'2 (2) 



r v'D l:C ^ D 9 sli n a 1 1 o Addfe s S;.(6)*iA;/\ 



DLC Protocol (2) 



Network Destination Address (16) 



Network Source Address (16) 



Network Protocol (2) 





r-^i Ifunnel/Soj^rbe^d '^l ^ 



Tunnel Protocol (2) 



Application Protocol (2) 



Destination Connection (4) 



Source Connection (4) 



Analyzer 
Extracted Input Data 
(96 bytes) 
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3.1.2 Flow Entry Description 

3.2 Architectural Block Diagram 



Unified Flow Key 
Buffer - UFKB 



Lool(Up/Update 
Engine - LUE 



State Processor - SP 
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Processor 
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FIDE 



Caclie 



Analyzer CPU 
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Control • ACIC 
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4 Top Level MeterFlow Accelerator Analyzer Module Symbol 



ANA.TOP 



Reset_N 
MCLK 



MemClkIn 
MemDataln[63:0] 



AnalyzerSeLN 
HostWrite 
HostBlast_N 
HostWaiLN 

HostAdclress[21:0] 
HostByteEn_N(7:0) 



MemRAS.Nn:0) 

MemCAS^N[3:0] ^— 

MemClkEn 
MemClkOut 
MemWR.N 
MemBA 
MemDSF 

MemByteEn.NI7:0] 
MemAcidclress{11:01 

MemDataOut[63:0] 

MemDirRead 
AnaHostReady_N 



HostDataln[63:0] AnaHostDataOut[63:0] — 



ParserKeyDelim 
ParserDataAvail 
ParserData[63:0] 



AnalyzerReady — • 



Technically Elite MeterFlow Accelerator Analyzer Module Specification 
Confidential Page 10 of 51 



Technically Elite 



CONFIDENTIAL 



5 MeterFlow Accelerator Analyzer Module Top Level Pin 
Descriptions 



5.1.1.1 General Interface Signals 


Signal 


Dir 


Widtli 


Description 


Reset^N 


IN 


1 


Reset - active low. 

When this signal is active the analyzer sets it*s registers to 
their default condition and suspends operation. It will only 
respond to host access cycles. 


MCLK 


IN 


1 


Module Clock. 

All internal and external transfers except for memory 
transfers are synchronized by this signal. 




5.1.1.2 Memory Interface 


Signal 


Dir 


Width 


Description 


MemClkIn 


IN 


1 


Memory clock in. 

This signal is used to generate the memory interface timing. 


MemRAS.N 


OUT 


* 


Memory Row Address Strobe bus - active low. 
* uses AN_MEM„RASWIDTH 


MemCAS^N 


OUT 


# 


Memory Column Address Strobe bus- active low. 
* uses AN_MEM^CASWIDTH 


MemClkEn 


OUT 


1 


Memory Clock Enable. 

Some memories require this signal to be disabled for a 
certain amount of time after reset. 


MemClkOut 


OUT 


1 


Memory Clock Out. 

This signal is used by synchronous memory for all 
operations. MemClkIn is buffered and sent out on this pin. 

This helps reduce skew between this clock and the other 
signals. 


MemWR_N 


OUT 


1 


Memory Write - active low. 


MemBA 


OUT 


1 


Memory Bank Address. 

Used by multi-bank memory to select the bank the current 

operation is to operate on. 


MemDSF 


OUT 


I 


Memory Special Function select. 


MemByteEn^N 


OUT 




Memory Byte Enable bus- active low. 
* uses AN_MEM_BEWIDTH 


MemAddress 


OUT 


* 


Memory Address bus. 

* uses AN_MEM_AWIDTH 


MemDataln 


IN 




Memory Data Input bus. 
* uses AN_MEM„DWIDTH 


MemDataOut 


OUT 




Memory Data Output bus. 
* uses AN^MEM_DWIDTH 
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S.1.1.2 Memory Interface 


Signal 


Dir 


Width 


Description 


MemDirRead 


OUT 


1 


Memory Data bus Direction is Read. 
This signal is used to control the tri-state enable on the 
bidirectional memory data bus. If MemDirRead is active 
data is coming into the analyzer from the memory. If it is 
inactive the analyzer is driving data out to the memory. 



5.1.1.3 Host Interface Signals 


Signal 


Dir 


Width 


Description 


AnalyzerSeLN 


IN 


1 


Host interface Analyzer Select - active low. 
AnalyzerSeLN is sampled on the rising edge of MCLK. If it 
is active, it signifies that the external host is attempting to 
access the analyzer. 


HostWrite 


IN 


1 


Write. 

Write is sampled on the rising edge of MCLK. This signal is 
only valid when AnalyzerSeLN is active. If this signal is 
active, the host is attempting to write to the analyzer. Inactive 
this signal sign signifies a read from the analyzer. It should 
also be used to control the direction of the host data bus if it 
is bidirectional. 


HostBlast^N 


IN 


1 


Burst Last - active low. 

HostBlast.N is sampled on the rising edge of MCLK. 
HostBlast.N tells the analyzer that the current transfer is the 

last transfer in this burst. 


HostWait.N 


IN 


1 


Wait - active low. 

HostWait_N is sampled on the rising edge of MCLK. The 
host asserts HostWait_N when it wishes to slow transfers 
between itself and the analyzer. This could also be used by 
additional interface logic to slow transfers so it can multiplex 
the bus down to a smaller size without additional FIFOs. If 
wait is active, HostReady.N is blocked. 


AnaHostReady^N 


OUT 


1 


Analyzer to Host Ready - active low. 
AnaHostReady _N should be sampled on the rising edge of 
MCLK. The analyzer returns AnaHostReady _N when the 
current cycle is completed. For a write operation, 
AnaHostReady _N means that the HostDataIn bus has been 
latched. For a read operation AnaHostReady _N means that 
the requested data is on the HostDataOut bus and is valid. 
AnaHostReady _N is blocked by HostWait_N. 


HostAddress 


IN 


* 


Host Address bus. 

HostAddress is sampled on the rising edge of MCLK if 
AnalizerSeLN is active. This bus defines the first address in 
this burst to access in the 32 Megabyte address space of the 
analyzer. See Section x.x.x for the Address Utilization Map. 
* Uses AN„HOST_AWIDTH 


HostByteEn^N 


IN 


* 


Host Byte Enable bus - Active low. 

HostWait_N is sampled on the rising edge of MCLK. 

* Uses AN_HOST_BEWIDTH 
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5.1.1.3 Host 


Interfac 


e Signals 


Signal 


Dir 


Width 


Description 


HostDataIn 


IN 


* 


Host Data Input bus. 

HostDataIn is sampled on the rising edge of MCLK if 
HostWrite is active and HostWait_N is inactive. 
* Uses AN.HOST^DWIDTH 


AnaHostDataOut 


OUT 


* 


Analyzer Host Data Output bus. 

AnaHostDataOut should be sampled on the rising edge of 
MCLK. Data on this bus is valid during a read cycle when 
AnaHostReady _N is active. 
* Uses AN_HOST_DWIDTH 



5.1.L4 Parser Interface 


Signal 


Dir 


Width 


Description 


AnalyzerReady 


OUT 


1 


Analyzer Ready. 

This signal tells the parser that the analyzer can accept data. 


AnalyzerAbort 


OUT 


1 


Analyzer Abort. 

This signal tells the parser that the analyzer does not need 
any more of the flow key. 


ParserKeyDelim 


IN 


1 


Parser Key Delimiter. 

The ParserKeyDelim signal becomes active when the first 
quadword of a new key is ready to transfer to the analyzer. It 
goes inactive when the last quadword of the key is transferred 
or AnalyzerAbort Is active. 


ParserDataAvail 


IN 


1 


Parser Data Available. 

If this signal is active the data on the ParserData bus is valid. 


ParserData 


IN 


* 


Parser Data bus. 



5.1.1.5 Known Flow Interface 


Signal 


Dir 


Width 


Description 


PacketRef 


OUT 


* 


Packet Reference number bus. 

This bus outputs the packet reference number copied from 
the UFKB. 

* Uses AN_FR_WIDTH 


Protocol 


OUT 




Protocol bus. 

This bus outputs the highest level protocol the State 
Processor has determined the packet contains. 
* Uses AN.APP^WIDTH 


KnownFIowStb 


OUT 


1 


Known Flow Strobe. 

When this signal is active, the data on the PacketRef and the 
Protocol busses are valid. 
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6 MeterFlow Accelerator Analyzer Module Top Level VHDL 
Entity 

7 MeterFlow Accelerator Analyzer Module Top Level Veriiog 
Module 

8 MeterFlow Accelerator Analyzer Module Top Level Schematic 

Insert Schematic Here 
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9 Analyzer Module Constants Files 



The analyzer module constants files contain a list of constants used to allow rapid configuration of the 
module. For example the size of the Analyzer's input buffer data bus: 



constant AN_UFKB_DWIDTH : integer := 64; - Unified Flow Key Buffer Data Bus Width 

9. 1 Analyzer module Verilog Constants File - ParserConstants.v 

Insert AnalyzerConstants.v here 

9.2 Analyzer module VHDL Constants File - ParserConstants.vhd 

Insert AnalyzerConstants.vhd here 



Verilog 



*define AN_UFKB_DWIDTH 64 // Unified Flow Key Buffer Data Bus Width 



VHDL 
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10 Sub-module Descriptions 
10. 1 Unified Flow Key Buffer - UFKB 

10.1.1 Symbol 



10.1.2 Highlights 

• Scaleable implementation 

• Can be build from four separate dual port RAM ceils 

• Wraps either RAM instantiation or can be synthesized latches 

• Separate read and write interfaces 

10.1.3 Description 

The Unified Flow Key Buffer is a wrapper for the buffers that are used to store the flow keys from the 
Parser and modified flow keys from the Lookup and Update Engine and the State Processor. It is four 
ported with separate read and write interfaces. The four connections are to the Parser/Parser Interface 
Control the Lookup and Update Engine, the State Processor and the Flow Insertion and Deletion Engine. In 
the Unified Flow Key Buffer logic hides from the interface which of the buffers is being accessed. 

When the first word of the flow key arrives from the Parser, the Lookup and Update Engine is notified. The 
Lookup and Update Engine places the first address it wants on the LUEnUFKBAdd bus and asserts 
LUEnUFKBRdReq. If the address requested is in the buffer the Unified Flow Key Buffer asserts 
UFKBuLUERdy. If not it waits for either the data to arrive or the transfer is terminated. Once the Lookup 
and Update Engine finishes processing the flow key it asserts LUEDone. At the same time it will assert 
LUEHoldBuf. LUEHoldBuf tells the system that the buffer is to be sent to the State Processor. 

The State Processor and Flow Insertion and Deletion Engine have similar interfaces except that the data is 
assumed to be already in the buffer so no ready is returned. Also Flow Insertion and Deletion Engine has no 
need to hold the buffer for another process so that once FIDEDone is asserted the buffer is freed. 

10.1.4 Implementation Information 

The module can be synthesized or RAM cells can be instantiated into the wrapper. The instantiated RAM 
should be four separate dual ported RAM cells. 

The RAM must complete a write or read in a single cycle with simultaneous read and write to SEPARATE 
locations. 

10.1.5 File Names 
Top: UFKB.v(hd) 

Uses: AnalyzerConstants.v(hd), Generic4PortRAM.v(hd) 



10.1.6 Pin Descriptions 



10.1.6.1 


General Interface Signals 




Signal 


1 Dir 1 Width I 


Description 
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10.1.6.1 General Interface Signals 


Signal 


Dir 


Width 


Description 


Reset_N 


IN 


1 


Reset - active low. 


MCLK 


IN 


1 


Module Clock. 


AnalyzerEn 


IN 


1 


Analyzer Enable bit from the control register 



10.1.6.2 Parser Interface 



Signal 



Dir 



Width 



Description 



AnalyzerReady 



OUT 



1 



Analyzer Ready. 

This signal tells the parser that the analyzer can accept data. 



AnalyzerAbort 



OUT 



Analyzer Abort. 

This signal tells the parser that the analyzer does not need 
any more of the flow key. It is generated if the Lookup and 
Update Engine asserts LUEDone and not LUEHoldBuf 
before ParserKeyPelim goes inactive. 



ParserKeyDelim 



IN 



Parser Key Delimiter. 

The ParserKeyDelim signal becomes active when the first 
word of a new key is ready to transfer to the analyzer. It goes 
inactive when the last word of the key is transferred. 



ParserDataAvail 



IN 



Parser Data Available. 

If this signal is active, the data on the ParserData bus is 
valid. 



10.1.6.3 Lookup and Update Engine Interface 


Signal 


Dir 


Width 


Description 


UFKBuLUEData 


OUT 


* 


Unified Flow Key Buffer to Lookup and Update Engine read 
Data bus. 

* Uses AN UFKB_DWIDTH 


LUEnUFKBData 


IN 


* 


Lookup and Update Engine to Unified Flow Key Buffer write 
Data bus. 

* Uses AN UFKB DWIDTH 


LUEnUFKBAdd 


IN 


* 


Lookup and Update Engine to Unified Flow Key Buffer 
Address bus. 

♦Uses AN UFKB AWIDTH 


FIowKeySt 


OUT 


1 


Flow Key Start. 

This signal tells the Lookup and Update Engine that the 
Unified Flow Key Buffer module has placed the first word of 
a flow key buffer. 


UFKBuLUERdy 


OUT 


1 


Unified Flow Key Buffer to Lookup and Update Engine 
Ready. 


UFKBuLUEErr 


OUT 


1 


Unified Flow Key Buffer to Lookup and Update Engine 
Error. Asserted if a read request times out. 


LUEnUFKBRdReq 


IN 


1 


Lookup and Update Engine to Unified Flow Key Buffer Read 
Request. 


LUEnUFKBWrStb 


IN 


1 


Lookup and Update Engine to Unified Flow Key Buffer 
Write Strobe. 
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10.1.6.3 Lookup and Update Engine Interface 


Signal 


Dir 


Width 


Description 


LUEDone 


IN 


1 


Lookup and Update Engine Done. 

This input is used to tell the Unified Flow Key Buffer that the 
Lookup and Update Engine has finished with the current 
flow. The Unified Flow Key Buffer also uses this signal to 
increment it's internal pointer so that the next address from 
Lookup and Update Engine will point to the next flow buffer. 


LUEHoldBuf 


IN 


1 


Lookup and Update Engine Hold Buffer. 
This input is used to tell the Unified Flow Key Buffer that the 
Lookup and Update Engine is transferring processing of this 
buffer to the State Processor. 



10.1.6.4 State Processor Interface 


Signal 


Dir 


Width 


Description 


UFKBuSPData 


OUT 


* 


Unified Flow Key Buffer to Stale Processor read Data bus. 
* Uses AN^UFKB^AWIDTH 


SPrUFKBData 


IN 


* 


State Processor to Unified Flow Key Buffer write Data bus. 
* Uses AN^ UFKB _AWIDTH 


SPrUFKBAdd 


IN 


* 


State Processor to Unified Flow Key Buffer Address bus. 
* Uses AN_ UFKB _AWIDTH 


SPFlowKeyAv 


OUT 


1 


State Processor Flow Key Available. 

This signal tells the State Processor that the Unified Flow 

Key Buffer module a flow key for it to process. 


SPrUFKBWrStb 


IN 


1 


State Processor to Unified Flow Key Buffer Write Strobe. 


SPDone 


IN 


1 


State Processor Done. 

This input is used to tell the Unified Flow Key Buffer that the 
State Processor has finished with the current flow. The 
Unified Flow Key Buffer also uses this signal to increment 
it*s internal pointer so that the next address from State 
Processor will point to the next flow buffer. 


SPHoidBuf 


IN 


1 


State Processor Hold Buffer. 

This input is used to tell the Unified Flow Key Buffer that the 
State Processor is transferring processing of this buffer to the 
Flow Insertion and Deletion Engine. 



10.L6.5 Flow Insertion and Deletion Engine Interface 


Signal 


Dir 


Width 


Description 


UFKBuFIDEData 


OUT 


* 


Unified Flow Key Buffer to Flow Insertion and Deletion 

Engine read Data bus. 

* Uses AN_UFKB_A WIDTH 


FIDEnUFKBAdd 


IN 


* 


Flow Insertion and Deletion Engine to Unified Flow Key 

Buffer Address bus. 

* Uses AN_ UFKB _AWIDTH 


FIDEFIowKeyAv 


OUT 


1 


Flow Insertion and Deletion Engine Flow Key Available. 
This signal tells the Flow Insertion and Deletion Engine that 
the Unified Flow Key Buffer module a flow key for it to 
process. 
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10.1.6.5 Flow Insertion and Deletion Engine Interface 


Signal 


Dir 


Width 


Description 


FIDEDone 


IN 


I 


Flow Insertion and Deletion Engine Done. 
This input is used to tell the Unified Flow Key Buffer that the 
Flow Insertion and Deletion Engine has finished with the 
current flow. The Unified Flow Key Buffer also uses this 
signal to increment it's internal pointer so that the next 
address from Flow Insertion and Deletion Engine will point 
to the next flow buffer. 



10.1.7 Verilog Module 



module UFKB( Reset_N, MCLK ,AnalyzGrEn , Anal yzerReady , Anal yzerAbort 
,ParserKeyDel im , ParserDataAvai 1 ,UFKBuLUEData , LUEnUFKBData 
,LUEnUFKBAdd ,FlowKeySt ,UFKBuLUERdy ,UFKBuLUEErr , LUEnUFKBRdReq 
.LUEnUFKBWrStb ,LUEDone ,LUEHoldBuf ,UFKBuSPData ,SPrUFKBData 
,SPrUFKBAdd ,SPFlowKeyAv , SPrUFKBWrStb ,SPDone ,SPHoldBuf ,UFKBuFIDEData 
,FIDEnUFKBAdd , FIDEFl owKeyAv , FIDEDone); 

// General Interface Interface 

input Reset_N; 

input MCLK; 

input AnalyzerEn; 

// Parser Interface 

output AnalyzerReady ; 

output AnalyzerAbort ; 

input ParserKeyDelim; 

input ParserDataAvall ; 

// Lookup and Update Engine Interface 

output [^AN^UFKB_.DWIDTH-1 : 0] UFKBuLUEData ; 

input [^AN_UFKB_DWIDTH-1 : 03 LUEnUFKBData; 

input [^AN„UFKB_AWIDTH-1 : 0] LUEnUFKBAdd; 

output FlowKeySt; 

output UFKBuLUERdy; 

output UFKBuLUEErr; 

input LUEnUFKBRdReq; 

input LUEnUFKBWrStb; 

input LUEDone; 

input LUEHoldBuf; 

// State Processor Interface 

output [^AN_UFKB_DWIDTH-1 : 0] UFKBuSPData; 

input [^AN_UFKB^DWIDTH-1 : 0] SPrUFKBData; 

input [^AN_UFKB_AWIDTH-1 : 0] SPrUFKBAdd; 

output SPFIowKeyAv; 

input SPrUFKBWrStb; 

input SPDone; 

input SPHoldBuf; 

// Flow Insertion and Deletion Engine 

output [^AN^UFKB_DWIDTH-1 : 0] UFKBuFI DEDa ta ; 
input [^AN.UFKB.AWIDTH-1 : 0] FIDEnUFKBAdd ; 
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output FIDEFIowKeyAv; 
input FIDEDone; 

10.1.8 VHDL Component 
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10.2 Lookup and Update Engine - LUE 

10.2.1 Symbol 



10.2.2 Highlights 

• Looks up flow entries 

• Compares flow key from parser to flow entries 

• Updates packet count and byte count tables 

• 64 bit byte count adder with early out 

• Checks flow state to see if processing by the state processor is required 

10.2.3 Description 

The Lookup and Update Engine begins processing as soon as a flow key arrives from the parser. The first 
transfer from the parser contains a hash value that is used as an offset into the flow entry database. The LUE 
checks the entry to see if it matches the flow key by comparing the unique identification for that flow. If 
there is a match, the LUE updates the counters for the flow entry. The LUE also check the entry's flow state 
to see if the flow key needs to be sent to the slate processor. 

The Lookup and Update Engine also outputs on a special data bus, two 16 bit values. One value is a word 
from the flow key that can be a packet identifier or any thing else the design wants. The other is the protocol 
identifier for the flow. This can be programmed to output this data on every packet or only for packets that 
the corresponding flow is in the IDENTIFIED state. 

10.2.4 Implementation Information 



10.2.5 File Names 

Top: LUE.v(hd) 

Uses: AnalyzerConstants.v(hd) 



10.2.6 Pin Descriptions 



10.2.6.1 General Interface Signals 


Signal 


Dir 


Width 


Description 


Reset N 


IN 


1 


Reset - active low. 


MCLK 


IN 


1 


Module Clock. 


AnalyzerEn 


IN 


1 


Analyzer Enable bit from the control register 



10.2.6.2 Unified FIom^ Key Buffer Interface 


Signal 


Dir 


Width 


Description 


UFKBuLUEData 


IN 




Unified Flow Key Buffer to Lookup and Update Engine read 
Data bus. 

* Uses AN_UFKB^DWIDTH 
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10.2.6.2 Unified Flow Key Buffer Interface 



Signal 


Dir 


Width 


Description 


LUEnUFKBData 


OUT 


* 


Lookup and Update Engine to Unified Flow Key Buffer write 
Data bus. 

* Uses AN UFKB _DWIDTH 


LUEnUFKBAdd 


OUT 




Lookup and Update Engine to Unified Flow Key Buffer 

Address bus 

* Uses AN UFKB_AWIDTH 




TN 




Flow Kev Start 

This signal tells the Lookup and Update Engine that the 
Unified Flow Key Buffer module has placed the first word of 
a flow key buffer. 


T IFKRiiT.T JERdv 


IN 




Unified Flow Key Buffer to Lookup and Update Engine 

Ready. 


UFKBuLUEErr 


IN 




Unified Flow Key Buffer to Lookup and Update Engine 
Error. Asserted if a read request times out. 


LUEnUFKBRdReq 


OUT 




Lookup and Update Engine to Unified Flow Key Buffer Read 

Request. 


LtUlLnUr J\,l> W roiD 


OUT 




Lookup and Update Engine to Unified Flow Key Buffer 
Write Strobe. 


LUEDone 


OUT 


■ 


Lookup and Update Engine Done. 

This input is used to tell the Unified Flow Key Buffer that the 
Lookup and Update Engine has finished with the current 
flow. The Unified Flow Key Buffer also uses this signal to 
increment it's internal pointer so that the next address from 
Lookup and Update Engine will point to the next flow buffer. 


LUEHoldBuf 


OUT 


I 


Lookup and Update Engine Hold Buffer. 
This input is used to tell the Unified Flow Key Buffer that the 
Lookup and Update Engine is transferring processing of this 
buffer to the State Processor. 




10.2.63 Cache Interface 


Signal 


Dir 


Width 


Description 


CaLUEReady 


IN 


1 


Cache to Lookup Engine Ready. 
This signal tells the Lookup Engine that during a read, the 
data on the CaLUEData bus is valid and during a write that 
the Cache has latched the data on the LUEnCaData bus. 


CaLUEData 


IN 


* 


Cache to Lookup Engine Data bus. 
* Uses AN CA DWIDTH 


LUEnCaData 


OUT 


* 


Lookup Engine to Cache Data bus. 
* Uses AN CA DWIDTH 


LUEAdd 


OUT 


* 


Lookup Engine to Cache Address bus. 
* Uses AN CA AWIDTH 


LUEMemReq 


OUT 


1 


Lookup Engine Memory Request. 

If this signal is active, the address on the LUEAdd bus is 

valid. 


LUEMemWr 


OUT 


1 


Lookup Engine Memory Write. 

If this signal is active, the current transaction is a write.. 



Confidential 



Technically Elite MeterFlow Accelerator Analyzer Module Specification 

Page 22 of 51 



Technically Elite CONFIDENTIAL 



10.2.6.4 Kno^ 


ivn Flow Interface 


Signal 


Dir 


Width 


Description 


PacketRef 


OUT 


* 


Packet Reference number bus. 

This bus outputs the packet reference number copied from 
the UFKB. 

* Uses AN_FR_WIDTH 


Protocol 


OUT 




Protocol bus. 

This bus outputs the highest level protocol the State 
Processor has determined the packet contains. 
* Uses AN.PRO.WIDTH 


KnownFlowStb 


OUT 


1 


Known Flow Strobe. 

When this signal is active, the data on the PacketRef and the 
Protocol busses are valid. 



10.2.7 Verilog Module 

module LUE(Reset_N, MCLK .AnalyzerEn .UFKBuLUEData , LUEnUFKBData 
.LUEnUFKBAdd .FIowKeySt .UFKBuLUERdy .UFKBuLUEErr , LUEnUFKBRdReq 
.LUEnUFKBWrStb .LUEDone .LUEHoldBuf .CaLUEData .LUEnCaData .LUEAdd 
.LUEMemReq .LUEMemWr); 

// General Interface Interface 
input Reset_N; 
input MCLK; 

input AnalyzerEn; 

// Unified Flow Key Buffer Interface 

input ['AN_UFKB_DWI0TH-1 : 0] UFKBuLUEData; 

output ['AN_UFKB_DWIDTH-1 : 0] LUEnUFKBData; 

output C'AN_UFKB_AWIDTH-1 : 0] LUEnUFKBAdd; 

input FlowKeySt; 

input UFKBuLUERdy; 

input UFKBuLUEErr; 

output LUEnUFKBRdReq; 

output LUEnUFKBWrStb; 

output LUEDone; 

output LUEHoldBuf; 

// Cache Interface 

input CaLUEReady; 

input C^AN_CA_DWIDTH-1 : 0] CaLUEData; 

output [^AN_CA_DWIDTH-1 : 0] LUEnCaData; 

output C~AN_CA_AWIDTH-1 : 0] LUEAdd; 

output LUEMemReq; 

output LUEMemWr; 

// Known Flow Interface 

output ['AN_FR_WIDTH-1 : 0] PacketRef; 

output [^AN_PR0_WIDTH-1 : 0] Protocol; 

output KnownFlowStb; 

10.2.8 VHDL Component 
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10.3 Analyzer CPU Interface and Control • ACIC 

10,3.1 Symbol 



10.3.2 Description 

The Analyzer CPU Interface Control module controls the communication between the external CPU and the 
Analyzer. The ACIC contains MUX's for the CPU read back path. It also contains the control register for 
the Analyzer. 

10.3.3 File Names 

Top: ACIC.v(hd) 

Uses: AnalyzerConstants.v(hd) 



10.3.4 Pin Descriptions 



10.3.4.1 General Interface Signals 


Signal 


Dir 


Width 


Description 


Reset.N 


IN 


1 


Reset - active low. 


MCLK 


IN 


1 


Module Clock. 


AnalyzerEn 


OUT 


1 


Analyzer Enable bit from the control register 



10.3.4.2 Host Interface Signals 


Signal 


Dir 


Width 


Description 


AnalyzerSeLN 


IN 


1 


Host interface Analyzer Select - active low. 
AnalyzerSeLN is sampled on the rising edge of MCLK. If it 
is active, it signifies that the external host is attempting to 
access the analyzer. 


HostWrite 


IN 


1 


Write. 

Write is sampled on the rising edge of MCLK. This signal is 
only valid when AnalyzerSeLN is active. If this signal is 
active, the host is attempting to write to the analyzer. Inactive 
this signal sign signifies a read from the analyzer. It should 
also be used to control the direction of the host data bus if it 
is bidirectional. 


HostBlast^N 


IN 


1 


Burst Last - active low, 

HostBlast_N is sampled on the rising edge of MCLK. 
HostBlast.N tells the analyzer that the current transfer is the 
last transfer in this burst. 


HostWait^N 


IN 


1 


Wait - active low, 

HostWait_N is sampled on the rising edge of MCLK. The 
host asserts HostWait_N when it wishes to slow transfers 
between itself and the analyzer. This could also be used by 
additional interface logic to slow transfers so it can multiplex 
the bus down to a smaller size without additional FIFOs. If 
wait is active, HostReady_N is blocked. 
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10.3.4.2 Host Interface Signals 



Signal 


Dir 


Width 


Description 


AnanosiJieaay^Pi 


OT IT 


1 
1 


Analv/er to Host Readv — active low. 
AnaHostReady _N should be sampled on the rising edge of 
MCLK. The analyzer returns AnaHostReady _N when the 
current cycle is completed. For a write operation, 
AnaHostReady _N means that the HostDataIn bus has been 
latched. For a read operation AnaHostReady _N means that 

ttio t-AmiAcfpH H^fa ic on thp T4rkcf OatfiOiit nnfi i<S VAlid 
Xne reUUCalCU Uala \Jl\ iKxJaVUavaxJXiv uua aiiu lo vaiivii 

AnaHostReady N is blocked by HostWait^N. 


HostAddress 


IN 




Host Address bus. 

riostAflaress is sampiea on ine rising euge ui iviv-^l*iv u 
AnalizerSeLN is active. This bus defines the first address in 
this burst to access in the 32 Megabyte address space of the 
analyzer. See Section x.x.x for the Address Utilization Map. 
* I kes AN HOST AWIDTH 


HostByteEn^N 


IN 




Host Byte Enable bus - Active low. • 

HostWait^N is sampled on the rising edge of MCLK. 

* Uses AN HOST BEWIDTH 


HostDataIn 


IN 




Host Data Input bus. 

HostDataIn is sampled on the rising edge of MCLK if 
HostWrite is active and HostWait.N is inactive. 

* Uses AN HOST DWIDTH 


AnaHostDataOut 


OUT 


* 


Analyzer Host Data Output bus. 

AnaHostDataOut should be sampled on the rising edge of 
MCLK. Data on this bus is valid during a read cycle when 
AnaHostReady _N is active. 
* Uses AN HOST DWIDTH 






10.3.4.3 Cache Interface 


Signal 


Dir 


Width 


Description 


CaACICReady 


IN 


1 


Cache to Analyzer CPU Interface Conuol Ready, 
This signal tells the Analyzer CPU Interface Control that 
during a read, the data on the CaACICData bus is valid and 
during a write that the Cache has latched the data on the 
ACICnCaData bus. 


CaACICData 


IN 


* 


Cache to Analyzer CPU Interface Control Data bus. 
* Uses AN CA DWIDTH 


ACICoCaData 


OUT 




Analyzer CPU Interface Control to Cache Data bus. 
* Uses AN CA DWIDTH 


ACICAdd 


OUT 


* 


Analyzer CPU Interface Control to Cache Address bus. 
* Uses AN CA AWIDTH 


ACICMemReq 


OUT 


1 


Analyzer CPU Interface Control Memory Request. 

If this signal is active, the address on the ACICAdd bus is 

valid. 


ACICMemWr 


OUT 


1 


Analyzer CPU Interface Control Memory Write. 

If this signal is active, the current transaction is a write.. 
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10.3.4.4 State 


i Process 


or Instruction Database Interface 


Signal 


Dir 


Width 


Description 


ACICoSProWr 


OUT 


1 


Analyzer CPU Interface Control to State Processor 
Instruction Database Write Strobe 


ACICoSProAdd 


OUT 


* 


Analyzer CPU Interface Control to State Processor 
Instruction Database Address bus 
* uses AN^SPID_AWIDTH 




TKT 


* 


State Processor Instruction Database Data bus 
* uses AN_SPID ^DWIDTH 


ACICoSPIDData 


OUT 


* 


Analyzer CPU Interface Control to State Processor 
Instruction Database Data bus 
* uses AN_SPID _DWIDTH 



10.3.5 Verilog Module 

module ACIC(Reset_N, MCLK ,Analy2erEn , AnalyzerSeUN ,HostWr1te 
,HostBlast_N ,HostWait_N , AnaHostReady_N ,HostAddress ,HostByteEn_N 
,HostOataIn , AnaHostDataOut ,CaACICReady ,CaACICData ,ACICoCaData 
,ACICAdd . ACICMemReq .ACICMemWr ,ACICoSPIDWr ,ACICoSPIDAdd ,SPIDData 
, ACICoSPIDData); 

// General Interface Interface 

input ResGt_N; 

input MCLK; 

output AnalyzerEn; 

// Host Interface 

input AnalyzerSe1_N; 

input HostWrite; 

input HostBlast_N; 

input HostWait_N; 

output AnaHostReady_N ; 

input [^ANJOST^AWIDTH'l : 0] HostAddress; 
input [^AN.H0ST3EWIDTH-1 : 0] HostByteEn_N ; 
input C^AN_HOST^DWIDTH'l : 0] HostDataIn; 
output [^AN_H0ST_DWIDTH-1 : 0] AnaHostDataOut; 
// Cache Interface 
input CaACICReady; 

input C^AN_CAJWIDTH-1 : Oj CaACICData; 
output [^AN_CA_DWIDTH-1 : 0] ACICoCaData; 
output [^AN_CA_AWIDTH-1 : 0] ACICAdd; 
output ACICMemReq; 
output ACICMemWr; 

// State Processor Instruction Database Interface 
output ACICoSPIDWr; 

output [^AN_SPID_AWIDTH-1 : 0] ACICoSPIDAdd ; 

input [^AN__SPID_DWIDTH-1 : 0] SPIDData; 
output [^AN„SPID_DWIDTH-1 : 0] ACICoSPIDData; 

10.3.6 VHDL Component 



Technically Elite MeterFloM^ Accelerator Analyzer Module Specification 
Confidential Page 26 of 5 1 



Technically Elite 



CONFIDENTIAL 



10.4 Flow Insertion and Deletion Engine - FIDE 

10.4.1 Symbol 



10.4.2 Highlights 

• Maintains flow entry database 

• Deletes and inserts flows based on a LRU algorithm 

• Builds flows from flow key and State Processor instructions 

10.4.3 Description 

The Flow Insertion and Deletion Engine maintains the flow entry database. Flows are grouped into buckets 
by hash value. When a new flow needs to be inserted first the FIDE sees which of the entries 
in the corresponding bucket is the oldest. It then builds the flow entry from the flow key and State Processor 
instructions. Finally it places the entry in the database. 

10.4.4 Implementation Information 



10.4.5 File Names 

Top: FIDE.v(hd) 

Uses: AnalyzerConstants.v(hd) 

10.4.6 Pin Descriptions 



10.4.6.1 General Interface Signals 



Signal 


Dir 


Width 


Description 


Reset N 


IN 


1 


Reset - active low. 


MCLK 


IN 


1 


Module Clock. 


AnalyzerEn 


IN 


1 


Analyzer Enable bit from the control register 






10.4.6.2 Unified Flow Key Buffer Interface 


Signal 


Dir 


Width 


Description 


UFKBuFIDEData 


IN 


* 


Unified Flow Key Buffer to Flow Insertion and Deletion 

Engine read Data bus. 

* Uses AN UFKB AWIDTH 


FIDEnUFKBAdd 


OUT 


* 


Flow Insertion and Deletion Engine to Unified Flow Key 

Buffer Address bus. 

* Uses AN UFKB AWIDTH 


FIDEFlowKeyAv 


IN 


1 


Flow Insertion and Deletion Engine Flow Key Available. 
This signal tells the Flow Insertion and Deletion Engine that 
the Unified Flow Key Buffer module a flow key for it to 
process. 
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10.4.6.2 


Unif 


led Flow 


Key Buffer Interface 1 


Signal 


Dir 


Width 


Description 


FIDEDone 


OUT 


1 


Flow Insertion and Deletion Engine Done. 
This input is used to tell the Unified Flow Key Buffer that the 
Flow Insertion and Deletion Engine has finished with the 
current flow. The Unified Flow Key Buffer also uses this 
signal to increment it*s internal pointer so that the next 
address from Flow Insertion and Deletion Engine will point 
to the next flow buffer. 




10.4.6.3 


Cacli 


le Interface 


Signal 


Dir 


Width 


Description 


CaFIDEReady 


IN 


1 


Cache to Flow Insertion and Deletion Engine Ready. 
This signal tells the Flow Insertion and Deletion Engine that 
during a read, the data on the CaFIDEData bus is valid and 
during a write that the Cache has latched the data on the 
FIDEnCaData bus. 


CaFIDEData 


IN 




Cache to Flow Insertion and Deletion Engine Data bus. 
* Uses AN CA DWIDTH 


FIDEnCaData 


OUT 


He 


Flow Insertion and Deletion Engine to Cache Data bus. 
* Uses AN CA DWIDTH 


FIDEAdd 


OUT 




Flow Insertion and Deletion Engine to Cache Address bus. 
* Uses AN_CA_AWIDTH 


FIDEMemReq 


OUT 


1 


Flow Insertion and Deletion Engine Memory Request. 
If this signal is active, the address on the FIDEAdd bus is 

valid. 


FIDEMemWr 


OUT 


1 


Flow Insertion and Deletion Engine Memory Write. 
If this signal is active, the current transaction is a write.. 



10.4.7 Verilog Module 

module FIDE(Reset_N, MCLK ,Analy2erEn , UFKBuFIOEData , FIDEnUFKBAdd 
,FIDEFlowKeyAv , FIDEDone , CaFIDEData , FIDEnCaData , FIDEAdd , FIDEMemReq 
, FIDEMemWr); 



// General Interface Interface 
input Reset_N; 
input MCLK; 
input AnalyzerEn; 

// Unified Flow Key Buffer Interface 

input [^AN^UFKBJWIDTH-l : 0] UFKBuFIDEData ; 

output [^AN_UFKB_AWIDTH-1 : 0] FIDEnUFKBAdd ; 

input FIDEFlowKeyAv; 

output FIDEDone; 

// Cache Interface 

input CaFIDEReady; 

input [^AN_CA_DWIDTH-1 : 0] CaFIDEData; 
output [^AN^CAJWIDTH-l : 0] FIDEnCaData; 
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output [^AN^CA^AWIOTH-1 : 0] FIDEAdd; 
output FIDEMemReq ; 
output FIDEMemWr; 

10.4.8 VHDL Component 
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10.5 state Processor Instruction Database - SPID 

10.5.1 Symbol 

10.5.2 Highlights 

• Scaleable implementation 

• Wraps either RAM or ROM instantiation or can be synthesized latches 

10.5.3 Description 

The State Processor Instruction Database module is a wrapper for the storage medium used to hold the State 
Processor Instruction database. Only the CPU can write this memory. The CPU interface is active if 
AnalyzerEn is active. 

10.5.4 Implementation Information 

The module can be synthesized or a RAM or ROM cell can be instantiated into the wrapper. 

10.5.5 File Names 

Top: SPID.v(hd) 

Uses: AnalyzerConstants.v(hd) 



10.5.6 Pin Descriptions 



10.5.6.1 General Interface Signals 


Signal 


Dir 


Width 


Description 


Reset_N 


IN 


1 


Reset - active low. 


MCLK 


IN 


1 


Module Clock. 


AnalyzerEn 


IN 


1 


Analyzer Enable bit from the control register 



10.5.6.2 Analyzer CPU Interface Control Interface 


Signal 


Dir 


Width 


Description 


ACICoSPIDWr 


IN 


1 


Analyzer CPU Interface Control to State Processor 
Instruction Database Write Strobe 


ACICoSPIDAdd 


IN 


* 


Analyzer CPU Interface Control to State Processor 
Instruction Database Address bus 
* uses AN SPID AWIDTH 


SPIDData 


OUT 


* 


State Processor Instruction Database Data bus 
* uses AN SPID DWIDTH 


ACICoSPIDData 


IN 


* 


Analyzer CPU Interface Control to State Processor 
Instruction Database Data bus 
* uses AN SPID DWIDTH 
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10.5.6.3 State Processor Interface 


Signal 


Dir 


Width 


Description 


SPrSProAdd 


IN 


* 


State Processor to State Processor Instruction Database 
Address bus 

* uses AN_SPID_AWIDTH 



10.5.7 Verilog Module 

module SPIO(Reset_N, MCLK .AnalyzerEn .ACICoSPIDWr , ACICoSPIDAdd 
.SPIDData .ACICoSPIDOata .SPrSPIDAdd) ; 

// General Interface Interface 
input Reset_N; 
input MCLK; 
input AnalyzerEn; 

// Analyzer CPU Interface Control Interface 
input ACICoSPIDWr; 

input ['AN_SPID_AWIDTH-1 : 0] ACICoSPIDAdd; 
output ['AN_SPID_DWIDTH-1 : 0] SPIDData; 
input ['AN_SPID_DWIDTH-1 : 0] ACICoSPIDOata; 
// State Processor Interface 
input ['AN_SPI0_AWIDTH-1 : 0] SPrSPIDAdd; 

10.5.8 VHDL Component 
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10.6 Unified l\/lemory Controller - UMC 

10.6.1 Symbol 



10.6.2 Highlights 

• Supports Both SDRAM and SGRAM 

• Maintains RAM refresh 

10.6.3 Description 

The Unified Memory Controller module controls the caches' access to the flow database contained in 
external RAM. Synchronous DRAM is controlled through a series of instructions feed to the RAM through 
the control pins. Synchronous DRAM requires at startup a specific series of commands for initialization. 
The Unified Memory Controller handles both processes thorough a state machine. Since the nature of the 
flow database requires random access, there is little use in attempting to keep multiple banks open. Auto- 
refresh is continuous when memory is not being accessed by the cache. 

10.6.4 Implementation Information 

The Unified Memory Controller module is implemented as a Moore type finite state machine. Each of the 
outputs of the state machine are registered to assure maximum setup time for the external device. 

10.6.5 File Names 

Top: UMC.v(hd) 

Uses: AnalyzerConstants.v(hd) 



10.6.6 Pin Descriptions 



10,6.6.1 General Interface Signals 


Signal 


Dir 


Width 


Description 


Reset N 


IN 


1 


Reset - active low. 


MCLK 


IN 


1 


Module Clock. 


AnalyzerEn 


IN 


1 


Analyzer Enable bit from the control register 



10.6.6.2 Memory Interface 


Signal 


Dir 


Width 


Description 


MemCikIn 


IN 


1 


Memory clock in. 

This signal is used to generate the memory interface timing. 


MemRAS^N 


OUT 


* 


Memory Row Address Strobe bus - active low. 
* uses AN MEM RASWIDTH 


MemCAS_N 


OUT 


* 


Memory Column Address Strobe bus- active low. 
* uses AN MEM CASWIDTH 


MemClkEn 


OUT 


1 


Memory Clock Enable. 

Some memories require this signal to be disabled for a 
certain amount of time after reset. 
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10.6.6.2 Memory Interface 



Signal 


Dir 


Width 


Description 


MemClkOut 


OUT 


1 


Memory Clock Out. 

T'hic cionnl ic iicaH Kv cvnr'hrnnoii^ rnfmorv \C\T fill 
lllld olgJlat la UoCU Uy dyilWlH UllUUd JUwlllUljr ii^i tti» 

nnerations MemCllcIn is buffered and sent out on this oin. 
This helps reduce skew between this clock and the other 


MemWR_N 


OUT 


1 


Memory Write - active low. 


MemBA 


OTTT 
UU 1 


1 
1 


\At^rx\r\T\i Rank" AHHrPQC 
iVXCIlIUI Y lJuIlN V^UUICoo. 

Used by multi-bank memory to select the bank the current 

r%.r\^Tf\\\c\x\ ic \c\ rtn^rsktp on 
OpciallUn la vU upcidlC UU. 


MemDSF 


OUT 


1 


Memory Special Function select. 


MemByteEn_N 


UU 1 


•if. 


lYiemory oyic cnaoic uua— dL-iivc luw. 
* uses AN MEM BEWIDTH 


MemAddress 


OUT 


* 


Memory Address bus. 

* uses AN MEM AWIDTH 


MemDataln 


IN 


* 


Memory Data Input bus. 

* AN MFM DWIDTH 


MemDataOut 


OUT 


* 


Memory Data Output bus. 
* uses AN MEM DWIDTH 


MemDirRead 


OUT 


1 


Memory Data bus Direction is Read. 
This signal is used to control the tri-state enable on the 
bidirectional memory data bus. If MemDirRead is active 
data is coming into the analyzer from the memory. If it is 
inactive the analyzer is driving data out to the memory. 






10,6.6.3 Cache Interface 


Signal 


Dir 


Width 


Description 


UMCoCaReady 


IN 


1 


Unified Memory Controller to Cache Ready. 
This signal tells the Cache that during a read, the data on the 
UMCoCaData bus is valid and during a write that the 
Unified Memory Controller has latched the data on the 
CaUMCData bus. 


UMCoCaData 


IN 


* 


Unified Memory Controller to Cache Data bus. 
♦Uses AN CA DWIDTH 


CaUMCData 


OUT 


* 


Cache to Unified Memory Controller Data bus. 
* Uses AN CA DWIDTH 


CaUMCAdd 


OUT 


* 


Cache to Unified Memory Controller Address bus. 
* Uses AN CA AWIDTH 


CaMemReq 


OUT 


1 


Cache Memory Request. 

If this signal is active, the address on the CaUMCAdd bus is 

valid. 


CaMemWr 


OUT 


1 


Cache Memory Write. 

If this signal is active, the current transaction is a write.. 



10.6.7 Verilog Module 

module UMC(Reset_N, MCLK .AnalyzerEn .MemClkIn ,MemRAS_N ,MeinCAS_N 
.MetnClkEn , MemClkOut ,MemWR_N .MemBA , MemDSF .MemByteEn_N .MemAddress 
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,MemOataIn ,MemDataOut ,MemDi rRead ,UMCoCaReaciy ,UMCoCaData ,CaUMCData 
,CaUMCAdd ,CaMemReq .CaMemWr); 

// General Interface Interface 

input Reset_N; 
input MCLK; 
input AnalyzerEn; 
// Memory Interface 
input MemClkIn; 

output [^AN_MEM_RASWIDTH-1 : 0] MemRAS^^N; 
output [^AN^MEM_CASWIDTH-1 : 0] MemCAS_N; 

output MemClkEn; 
output MemClkOut; 
output MemWR_N; 
output MemBA; 
output MemDSF; 

output [^AN_MEM_BEWIDTH-1 : 0] MeniByteEn_N; 
output [^AN_MEM_AWIDTH-1 : 0] MemAddress; 
input [^AN^MEM^DWIDTH-1 : 0] MemDataIn; 
output [^AN_MEM_DWIDTH-1 : 0] MemDataOut; 
output MemDi rRead; 
// Cache Interface 
input UMCoCaReady; 

input [^AN_.CA_DWIDTH'l : 0] UMCoCaData; 
output [^AN^CAJWIDTH-l : 0] CaUMCData; 
output [^AN_CA_AWIDTH-1 : 0] CaUMCAdd; 
output CaMemReq; 
output CaMemWr; 

10.6.8 VHDL Component 
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10.7 Cache 

10.7.1 Symbol 

10.7.2 Highlights 

• Fully associative 

• True least recently used cache updating 

• Simultaneous one write and two reads. 

10.7.3 Description 

The Cache module contains a fully associative, true LRU cache memory. Full associatively is achieved 
through the use of a content addressable memory (CAM). The need for a fully associative cache arises from 
the fact that the hash uses to generate the initial look up into the flow entry database spreads the entries 
pseudo randomly throughout the memory. Each hash value corresponds to a bucket containing N flow 
entries. N is set by the designer (see section xxx). 

The Cache can service two read transfers at one time. If there are more than two read requests active at one 
time the Cache services them in the order shown in section xxx. 

The CAM contains the hash value associated with the corresponding bucket in the cache memory. When 
there is a cache hit, the CAM produces the most significant bits of the address in cache memory where the 
bucket is stored. The cache then accesses the cache memory at the address indicated concatenating the 
lower address bits provided by the requesting module. The cache then remembers that the requesting 
module had a cache hit and the memory location returned. This allows a cache lookup for a requesting 
module to occur only once per request. When the requesting module requires a different bucket, it drops 
then again raises its request and another CAM cycle is initiated. 

The least recently used algorithm requires the CAM to also be a stack. When there is a cache hit the CAM 
location that produced the hit is put on the top of the stack. The other locations above the hit location are 
shifted down to fill in the gap. If there is a miss, the bottom location is read to determine the address in the 
cache memory to put the new bucket. All the locations shifted down as normally. Finally the new hash value 
and cache memory address are put at the top of the stack. 

10.7.3.1 Priority 

The Cache processes requests from the attached modules in the following order: 

1 - LRU dirty write back. The Cache writes back the least recently used bucket if it is dirty so that there will 
always be a space for the fetching of cache misses. 

2 - Lookup and Update Engine. 

3 - State Processor. 

4 - Flow Insertion and Deletion Engine. 

5 - Analyzer CPU Interface and Control 

6 - Dirty write back from LRU -1 to MRU. When there is nothing else pending the Cache writes dirty 
entries back to memory. 
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10J.4 Implementation Information 



10.7.5 File Names 

Top: Cache.v(hd) 

Uses: AnalyzerConstants.v(hd) 



10.7.6 Pin Descriptions 



10.7.6.1 General Interface Signals 


Signal 


Dir 


Width 


Description 


Reset_N 


IN 


1 


Reset - active low. 


MCLK 


IN 


1 


Module Clock. 


AnalyzerEn 


IN 


1 


Analyzer Enable bit from the control register 



10.7.6.2 Unified Memory Controller Interface 


Signal 


Dir 


Width 


Description 


UMCoCaReady 


OUT 


1 


Unified Memory Controller to Cache Ready. 
This signal tells the Cache that during a read, the data on the 
UMCoCaData bus is valid and during a write that the 
Unified Memory Controller has latched the data on the 
CaUMCData bus. 


UMCoCaData 


OUT 


* 


Unified Memory Controller to Cache Data bus, 
* Uses AN CA DWIDTH 


CaUMCData 


IN 


# 


Cache to Unified Memory Controller Data bus. 
* Uses AN CA DWIDTH 


CaUMCAdd 


IN 




Cache to Unified Memory Controller Address bus. 
* Uses AN CA AWIDTH 


CaMemReq 


IN 


1 


Cache Memory Request, 

If this signal is active, the address on the CaUMCAdd bus is 
valid. 


CaMemWr 


IN 


1 


Cache Memory Write. 

If this signal is active, the current transaction is a write.. 



10.7.6.3 Flow Insertion and Deletion Engine Interface 



Signal 


Dir 


Width 


Description 


CaFIDEReady 


OUT 


1 


Cache to Flow Insertion and Deletion Engine Ready. 
This signal tells the Flow Insertion and Deletion Engine that 
during a read, the data on the CaFIDEData bus is valid and 
during a write that the Cache has latched the data on the 
FIDEnCaData bus 


CaFIDEData 


OUT 




Cache to Flow Insertion and Deletion Engine Data bus. 
* Uses AN CA DWIDTH 


FIDEnCaData 


IN 


* 


Flow Insertion and Deletion Engine to Cache Data bus. 
* Uses AN CA DWIDTH 


FIDEAdd 


IN 


* 


Flow Insertion and Deletion Engine to Cache Address bus. 
* Uses AN CA AWIDTH 
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10.7.6,3 Flow Insertion and Deletion Engine Interface 


Signal 


Dir 


Width 


Description 


FIDEMemReq 


IN 


1 


Flow Insertion and Deletion Engine Memory Request. 
If this signal is active, the address on the FIDEAdd bus is 
valid. 


FIDEMemWr 


IN 


1 


Flow Insertion and Deletion Engine Memory Write. 
If this signal is active, the current transaction is a write.. 




10.7.6.4 Analyzer CPU Interface Control Interface 


Signal 


Dir 


Width 


Description 


CaACICReady 


OUT 


1 


Cache to Analyzer CPU Interface Control Ready. 
This signal tells the Analyzer CPU Interface Control that 
during a read, the data on the CaACICData bus is valid and 
during a write that the Cache has latched the data on the 
ACICnCaData bus. 


CaACICData 


OUT 


* 


Cache to Analyzer CPU Interface Control Data bus. 
* Uses AN_CA_DWIDTH 


ACICoCaData 


IN 


* 


Analyzer CPU Interface Control to Cache Data bus. 
* Uses AN^CA_DWIDTH 


ACICAdd 


IN 


* 


Analyzer CPU Interface Control to Cache Address bus. 
* Uses AN CA AWIDTH 


ACICMemReq 


IN 


1 


Analyzer CPU Interface Control Memory Request. 

If this signal is active, the address on the ACICAdd bus is 

valid. 


ACICMemWr 


IN 


1 


Analyzer CPU Interface Control Memory Write. 

If this signal is active, the current transaction is a write.. 




10.7.6.5 Lookup Engine Interface 


Signal 


Dir 


Width 


Description 


CaLUEReady 


OUT 


1 


Cache to Lookup Engine Ready. 

This signal tells the Lookup Engine that during a read, the 
data on the CaLUEData bus is valid and during a write that 
the Cache has latched the data on the LUEnCaData bus. 


CaLUEData 


OUT 




Cache to Lookup Engine Data bus. 
* Uses AN CA DWIDTH 


LUEnCaData 


IN 




Lookup Engine to Cache Data bus. 
* Uses AN CA DWIDTH 


LUEAdd 


IN 


* 


Lookup Engine to Cache Address bus. 
* Uses AN CA AWIDTH 


LUEMemReq 


IN 


1 


Lookup Engine Memory Request. 

If this signal is active, the address on the LUEAdd bus is 

valid. 


LUEMemWr 


IN 


1 


Lookup Engine Memory Write. 

If this signal is active, the current transaction is a write.. 
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10.7,6.6 State Process 


or Interface 


Signal 


Dir 


Width 


Description 


CaSPReady 


OUT 


1 


Cache to State Processor Ready. 

This signal tells the Lookup Engine that during a read, the 
data on the CaSPData bus is valid and during a write that the 
Cache has latched the data on the SPnCaData bus. 


CaSPData 


OUT 




Cache to State Processor Data bus. 
* Uses AN_CA_DWIDTH 


SPnCaData 


IN 


* 


State Processor to Cache Data bus. 
* Uses AN_CA_DWIDTH 


SPAdd 


IN 


* 


State Processor to Cache Address bus. 
* Uses AN_CA_AWIDTH 


SPMemReq 


IN 


1 


State Processor Memory Request. 

If this signal is active, the address on the SPAdd bus is valid. 


SPMemWr 


IN 


1 


State Processor Memory Write. 

If this signal is active, the current transaction is a write.. 



10.7.7 Verilog Module 

module Cache( Reset_N, MCLK .AnalyzerEn .UMCoCaReady .UMCoCaData 
.CaUMCData .CaUMCAdd .CaMemReq .CaMemWr .CaFIDEReady .CaFIDEData 
.FIDEnCaData .FIDEAdd .FIDEMemReq .FIDEMemWr .CaACICReady .CaACICData 
.ACICoCaData ,ACICAdd .ACICMemReq .ACICMemWr .CaLUEReady .CaLUEData 
.LUEnCaData .LUEAdd .LUEMemReq .LUEMemWr .CaSPReady .CaSPData .SPnCaData 
.SPAdd .SPMemReq , SPMemWr); 

// General Interface Interface 
input Reset_N; 
input MCLK; 
input AnalyzerEn; 

// Unified Memory Controller Interface 
output UMCoCaReady; 

output ["AN_CA_DWIDTH-1 : 0] UMCoCaData; 
input [~AN_CA_0WI0TH-1 : 0] CaUMCData; 
input C'AN_CA_AWIDTH-1 : 0] CaUMCAdd; 
input CaMemReq; 
input CaMemWr; 

// Flow Insertion and Deletion Engine Interface 
output CaFIDEReady; 

output [^AN_CA_DWIDTH-1 : 0] CaFIDEData; 
input C'AN_CA_DWIDTH-1 : 0] FIDEnCaData; 
input [-AN_CA_AWIDTH-1 : 0] FIDEAdd; 
input FIDEMemReq; 
input FIDEMemWr; 

// Analyzer CPU Interface Control Interface 
output CaACICReady; 

output C'AN_CA_DWIDTH-1 : 0] CaACICOata; 
input ['AN_CA_DWIDTH-1 : 0] ACICoCaData; 
input C-AN_CA_AWIDTH-1 : 0] ACICAdd; 
input ACICMemReq; 
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input ACICMemWr; 

// Lookup Engine Interface 

output CaLUEReady; 

output [^AN_CA_DWIDTH-1 : 0] CaLUEData; 

input [^AN_CA_DWIDTH-1 : 0] LUEnCaOata; 

input [^AN„CA_.AWI0TH-1 : 0] LUEAdd; 

input LUEMemReq; 

input LUEMemWr; 

// State Processor Interface 

output CaSPReady; 

output [^AN_CA^DWIDTH-1 : 0] CaSPData; 
input [^AN_CA_0WI0TH-1 : 0] SPnCaData; 
input [^AN_CA_AWIDTH-1 : 0] SPAdd; 
input SPMemReq; 
input SPMemWr; 

10.7.8 VHDL Component 
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10.8 State Processor - SP 

10.8.1 Symbol 

10.8.2 Highlights 

• Flexible Rule-based Traffic Classification 

• State-based Tracking of Traffic 

• Multiple Packets for Layer Processing 

• Programmable Rules/State Processor 

• Selectable Protocols in Flows 

• Future Protocols Support 

10.8.3 Description 

The State Processor module analyzes both new and existing flows in order to classify them by application. 
It does this by proceeding from state to state based on rules defined by the engineer. A rule is a test 
followed by the next state to proceed to if the test is true. The State Processor goes through each rule until 
the test is true or there are no more tests to perform. The State Processor starts the process by using the last 
protocol recognized by the Parser as an offset into a jump table. The jump table takes us to the instructions 
to use for that protocol. Most instructions test something in the Unified Flow Key Buffer or the flow entry if 
it exists. The State Processor may have to test bits, do comparisons, add or subtract to perform the test. 



10.8.4 Architecture 

The State Processor contains several sub-blocks: 

10.8.4. 1 Scratch Pad Registers 

The State Processor contains four scratch pad registers. These registers are the source and/or the destination 
for all instructions. It is implemented as a register file with one write and two read ports. 

10.8.4.2 Instruction Pointer and Stack 

The Instruction Pointer is used to point to the State Processor Instruction Database address that the State 
Processor is executing. The Instruction Pointer is initialized with the last protocol recognized by the Parser. 
This first instruction is a jump to the subroutine where the protocol is decoded. The State Processor 
supports calls so the Instruction Pointer block contains a two level stack. A one bit stack pointer points to 
the top of the stack that the Instruction Pointer is pushed to or popped from. 

10.8.4.3 Flag Register 

The Flag Register contains several bits used for conditional branching. 



10.8.4.3.1 



Flag Register Word Definition 



Bit 



Description 
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10.8.4.3.1 


Flag Register Word Definition 


Bit 


Description 











10.8.4.4 Compare Block 

The Compare Block compares two operands by exclusive-oring them together. The Compare Mask Register 
is contained in this block. If a bit is set in the Compare Mask Register, that bit is ignored in the compare 
operation. 

10.8.4.5 Flow Key Pointer 

The Flow Key Pointer provides the address that the State Processor is accessing in the Unified Flow Key 
Buffer. The Flow Key Pointer can perform both direct and indirect addressing. Indirect addressing is used 
to offset into a protocols' header. 

10.8.4.6 Flow Entry Pointer 

The Flow Entry Pointer provides the address that the State Processor is accessing in the Flow Entry in the 
Cache. If the flow entry exists, the upper address bits come from the hash used to lookup the bucket in the 
Flow database. The middle bits come from the bucket entry found. The lower bits come from the offset the 
State Processor is using. 

10.8.5 Instruction Definitions 

The following sections describe the instructions available in the State Processor. It should be noted that no 
assembler is provided for the State Processor. This is because the engineer need not write code for this 
processor. The MeterFlow Compiler writes the database entered into the State Processor Instruction 
Database from the protocols defined in the Protocol List. 

10.8.5.1 Jump 

This instruction causes the Instruction Pointer to be loaded with the address in the JumpAddress field of the 
State Processor Instruction Database. This instruction is always conditional. Whether the branch is taken or 
not depends on the on the ConditionCode field in the instruction and the state of the flag register. 

10.8.5.2 Call 

This instruction causes the Instruction Pointer to be loaded with the address in the JumpAddress field of the 
State Processor Instruction Database. At the same time the current address in the Instruction Pointer is 
pushed onto the stack. This instruction is always conditional. Whether the call is taken made or not depends 
on the on the ConditionCode field in the instruction and the state of the flag register. 

10.8.5.3 Return 

This instruction causes the Instruction Pointer to be loaded with the address at the top of the stack. This 
instruction is always conditional. Whether the return is executed or not depends on the on the 
ConditionCode field in the instruction and the state of the flag register. 
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10.8.5.4 Copy 

The Copy instruction moves data from: 

• Flow Key to Scratch Pad Register 

• Cache to Scratch Pad Register 

• ImmediateData to Scratch Pad Register 

• Scratch Pad Register to Flow Key 

• Scratch Pad Register to Cache 

• Scratch Pad Register to Compare Mask Register 

The external address can be either a direct or indirect access. 

10.8.5.5 Compare 

This instruction compares two operands . The operands must be either from a Scratch Pad Register or an 
immediate value from the instruction's ImmediateData field. The Compare Mask Register is used to set bit 
to don't care. 



10.8.5.6 Instruction Word Definition 


Bit 


Description 



















10.8.6 Implementation Information 



10,8.7 File Names 
Top: SP.v(hd) 

Uses: AnalyzerConstants.v(hd) 



10.8.8 Pin Descriptions 



10.8.8.1 General Interface Signals 


Signal 


Dir 


Width 


Description 


Reset_N 


IN 


1 


Reset - active low. 


MCLK 


IN 


1 


Module Clock. 


AnalyzerEn 


IN 


1 


Analyzer Enable bit from the control register 



10.8.8.2 


Unified Flow Key Buffer Interface 




Signal 


Dir Width 


Description 
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10.8.8.2 Unified Flow Key Buffer Interface 


Signal 


Dir 


Width 


Description 


UFKBuSPData 


IN 


* 


Unified Flow Key Buffer to State Processor read Data bus. 

* TTc#»c AM TTPk'R AWTHTH 
uscb Mil UFISJ3 r\ yy LU in 


brrVv KoLiata 


UU 1 




otate rrocessor lo uniiieo riow ivey jtjuirer write uata dus. 
* Uses AN^ UFKB ^AWIDTH 


SPrUFKBAdd 


OUT 


* 


State Processor to Unified Flow Key Buffer Address bus. 
* Uses AN. UFKB „AWIDTH 


SPFIowKeyAv 


IN 


1 


State Processor Flow Key Available. 

This signal tells the State Processor that the Unified Flow 

Key Buffer module a flow key for it to process. 


SPrUFKBWrStb 


OUT 


1 


State Processor to Unified Flow Key Buffer Write Strobe. 


SPDone 


OUT 


1 


State Processor Done. 

This input is used to tell the Unified Flow Key Buffer that the 
State Processor has finished with the current flow. The 
Unified Flow Key Buffer also uses this signal to increment 
it's internal pointer so that the next address from State 
Processor will point to the next flow buffer. 


SPHoldBuf 


OUT 


1 


State Processor Hold Buffer. 

This input is used to tell the Unified Flow Key Buffer that the 
State Processor is transferring processing of this buffer to the 
Flow Insertion and Deletion Engine. 




10.8.8.3 Cache Interface 


Signal 


Dir 


Width 


Description 


CaSPReady 


IN 


1 


Cache to State Processor Ready. 

This signal tells the Lookup Engine that during a read, the 
data on the CaSPData bus is valid and during a write that the 
Cache has latched the data on the SPnCaData bus. 


CaSPData 


IN 


* 


Cache to State Processor Data bus. 
* Uses AN.CA.DWIDTH 


SPrCaData 


OUT 


* 


State Processor to Cache Data bus. 
* Uses AN CA DWIDTH 


SPAdd 


OUT 


* 


State Processor to Cache Address bus. 
* Uses AN^CA.AWIDTH 


SPMemReq 


OUT 


1 


State Processor Memory Request. 

If this signal is active, the address on the SPAdd bus is valid. 


SPMemWr 


OUT 


1 


State Processor Memory Write. 

If this signal is active, the current transaction is a write.. 




10.8.8.4 State Processor Interface 


Signal 


Dir 


Width 


Description 


SPIDData 


IN 


* 


State Processor to State Processor Instruction Database Data 
bus 

* uses AN^SPID.DWIDTH 


SPrSPIDAdd 


OUT 


* 


State Processor to State Processor Instruction Database 
Address bus 

* uses AN_SPID_AWIDTH 
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10.8.9 Verilog Module 

module SP(Reset_N, MCLK ,AnalyzerEn ,UFKBuSPOata ,SPrUFKBData 
,SPrUFKBAdd ,SPnowKeyAv , SPnUFKBWrStb ,SPDone ,SPHoldBuf ,CaSPData 
,SPrCaData ,SPAdd ,SPMeniReq ,SPMemWr); 

// General Interface Interface 
input Reset_N; 
input MCLK; 
input AnalyzerEn; 

// Unified Flow Key Buffer Interface 
input [^AN_UFKB_DWIDTH-1 : 0] UFKBuSPData; 
output [^AN_UFKB_DWIDTH-1 : 0] SPrUFKBData; 
output C^AN^UFKB^AWIDTH-l : 0] SPrUFKBAdd; 
input SPFlowKeyAv; 
output SPrUFKBWrStb; 
output SPDone; 
output SPHoldBuf; 
// Cache Interface 
input CaSPReady; 

input [^AN_CA_DWIDTH-1 : 0] CaSPData; 
output [^AN_CA_DWIDTH-1 : 0] SPrCaOata; 
output [^AN^CA_AWI0TH-1 : 0] SPAdd; 
output SPMemReq; 
output SPMemWr; 

// State Processor Instruction Database 
input [^AN_SPID_DWIDTH-1 : 0] SPIDData; 
output [^AN_SPI0_AWI0TH-1 : 0] SPrSPIDAdd; 

10.8J0 VHDL Component 
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11 Appendix A - Multi-Packet State Processing 

11.1 Overview 

The MeterFlow Accelerator system is composed of four major subsystems. Each system interacts with the 
others by passing specific information and identification to parse, extract, generate flows and analyze single 
or multiple packets in data flow on a communications network. 

One of the major subsystems is the Analyzer. This component is responsible for creating and maintaining 
classified traffic flows, processing statistics for packets and flows, managing the traffic flow database and 
cache, and performing state-based analysis of traffic flows. 

This document describes the processes required for recognizing and maintaining state information for traffic 
flows. There are several different processes, which are detailed in the following sections. 

1 1.2 Analyzer Data Input Requirements 

In order for the Analyzer to successfully classify traffic by application, there are several data elements 
required from each packet to be analyzed. Prior to sending a packet of information to the Analyzer, all 
additional information must be formatted and sent along with the appropriate packet content. 

The Analyzer must specifically receive each packets in a conversation in the order which they are exchange 
between the client and the server. The order is crucial for proper state based classification. 

11.3 State-base Traffic Classification 

More applications running over data networks utilize complex methods of classifying traffic through the 
creation of multiple states. The creation of the state based traffic classification causes the need for 
managing and maintaining learned states from traffic derived in the network. 

There are several different methods in place for the creation of states in client/server network traffic. Even 
though there are several different methods for the creation of slate. It is possible to isolate these different 
approaches into two basic categories. 

The first category is commonly referred to as "server announcement". In the server announcement mode 
there are messages which are put out onto the network, in either a broadcast or multicast approach which, 
all stations in the network receive and decode to derive the appropriate connection point for communicating 
for that particular application, with the particular server. There are several examples for this type of server 
announcement implementation with state based protocols. Using the server announcement method, a 
particular application communicates using a service channel, in the form of a TCP or UDP socket or Port as 
in the IP protocol suite, or using a SAP as in the Novell IPX protocol suite. 

The second category is referred to as "in-stream analysis'*. This method is used either as a primary or 
secondary recognition process. As a primary process, in>stream analysis assists in extracting detailed 
information which will be used to further recognize both the specific application and application 
component. A good example of in-stream analysis is any Web-based applications. The commonly used 
PointCast Web information application can be recognized using this process. During the initial connection 
between a PointCast server and client, specific key tokens exist in the data exchange that will result in a 
signature for PointCast. 

The in stream analysis process may also be combined with the server announcement process. In many cases 
in stream analysis will augment other recognition processes. An example of combining in stream analysis 
with server announcement can be found in business applications such as SAP and BAAN. 

11.3.1 Session Tracking 

One of the primary processes for tracking applications in the stream of the client/server packet exchange, is 
through session tracking. The process of tracking sessions requires an initial connection to a predefined 
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socket or Port. This method of communication is used in a variety of transport layer protocols. It is most 
conmionly seen in the TCP and UDP transports of the IP protocol. 

During the process of session tracking, a client will make the request of a server using a specific Port or 
socket number. This initial request will cause the server to create a TCP or UDP Port to exchange the 
remainder of the data between the client and the server. The server then replies to the request of the client 
using this newly created Port. The original Port used by the client to connect to server will never be used 
again during this data exchange. 

One of the best examples of session tracking is TFTP. During the client/server exchange process of TFTP, 
a specific Port is always used to initiate the conversation. When the client begins the process of 
communicating, a request is made to UDP Port 67. Once the server receives this request, a new Port is 
created on the server. The server then replies to the client using the new Port. In this example, it is clear 
that in order to recognize TFTP the process must analyze the initial request from the client. Also, the reply 
from the server with the key Port information must be analyzed and used to create a key for monitoring the 
remainder of this data exchange. 

Another important component in session tracking is the understanding of the current state for particular 
connections in the network. Many of the application protocols, which can be monitored, are transported via 
protocols that have built-in state information. An example of such a transport protocol is TCP. This 
transport provides a reliable means of sending information between a client and a server. When he data 
exchange is initiated a TCP request for synchronization message is sent. This message contains a specific 
sequence number that is used to track and acknowledgement from the server. Once the server has 
knowledge to the synchronization request, data is exchange between the client and the server. When 
communications are no longer required, the client would send a finish or complete message to the server. 
The server willing knowledge this finish request, with a reply containing the sequence numbers from the 
request. This sequence of events is known as a connection oriented data exchange. Many of the events 
used to track the state in a conversation are directly related to these types of connection and maintenance 
messages. 

All of the processes discussed above are required to track sessions. The capability to track sessions is a 
requirement for understanding the current state to analyze. 

11.3«2 Server Announcement 

The process of server announcement consists of a server with multiple applications, which are all required 
to be simultaneously accessed from multiple clients. Many applications are beginning to use this process as 
a means of multiplexing a single Port or socket into many applications and services. The individual 
methods of server announcement protocols tend very. However, the basic underlying process remains 
similar between all of these different announcement exchanges. 

11.3.2,1 Sun RFC Analysis 

Sun-RPC and Net-RPC are to good examples of server announcement oriented communications processes. 
In this section we will analyze the requirements for recognizing applications which utilize the sun 
implementation of RPC. RPC stands for remote procedure call. This is a quite clear description of the 
process. A remote or client that wishes to use a server or procedure must establish a connection using the 
RPC protocol. 

Using the Sun-RPC protocol as a model for server announcement is completed through the following 
process. Each server running the Sun-RPC protocol must maintain a process and database called the Port 
Mapper. The Port Mapper creates a direct association between a Sun-RPC program or application and a 
TCP or UDP socket or Port. An application or program number is a 32-bit unique identifier assigned by 
lANA. Each Port Mapper on a Sun-RPC server can present the mappings between a unique program 
number and a specific transport socket through the use of specific request or a directed announcement. 

The first approach we will review is the specific request method. Using this process the client makes a 
specific request to the server on a predefined UDP or TCP socket. Once the Port Mapper process on the 
sun RPC server receives the request, the specific mapping is returned in a directed reply to the client. 

1 ) A client sends a TCP packet to Port 111, with an RPC Bind Lookup Request. 
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2) The server extracts the program identifier and version identifier from the request. The server also 
uses the fact that this packet came in the using the TCP transport. 

3) The server sends a TCP packet to Port 111, with an RPC Bind Lookup Reply. The reply contains 
the specific ports on which future transactions will be accepted for the specific RPC program 
identifier. 

1 1.3.2.2 Process for Sun RPC Analysis 

1 . Decode Sun RPC by TCP or UDP Port 1 1 1 

2. Check RPC type field for Id 

3. If value is PortMapper, save paired socket (i.e. dest for dest, src for src) 

4. Decode ports and mapping, save ports with socket/addr key 

5. There may be more than one pairing per mapper packet 

6. Saving is complete 
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PortMapper Protocol Specification (in RPC Language) 
const PMAP_PORT =111;/* portmapper port number */ 
A mapping of (program, version, protocol) to port number: 

struct mapping { unsigned int prog; unsigned int vers; unsigned int prot; unsigned int port; ); 
Supported values for the "prot" field: 

const IPPROTO_TCP = 6; /* protocol number for TCP/IP */ const IPPROTO.UDP = 17; /* protocol 
number for UDP/IP */ A list of mappings: struct *pmaplist { mapping map; pmaplist next; } ; 

Arguments to callil: struct call_args { unsigned int prog; unsigned int vers; unsigned int proc; opaque 
argso; ); Results of callit: struct calLresult { unsigned int port; opaque reso; ); Port mapper procedures: 
program PMAP.PROG { version PMAP_VERS { void PMAPPROC^NULL(void) = 0; bool 
PMAPPROC_SET(mapping) = 1; bool PMAPPROC^UNSET(mapping) = 2; unsigned int 
PMAPPROC_GETPORT(mapping) = 3; pmaplist PMAPPROC_DUMP(void) = 4; calLresult 
PMAPPROC_CALLIT(calLargs) = 5; } = 2; ) = 100000;A.2 Port Mapper Operation The portmapper 
program currently supports two protocols (UDP and TCP). The portmapper is contacted by talking to it on 
assigned port number 1 1 1 (SUNRPC) on either of these protocols. The following is a description of each of 
the portmapper 

Sun RPC Decode Process 

1 ) Parse frame to TCP or UDP 

2) Lookup paired sockets if no standard match 

3) If RPC found, same new Key 

The port mapper program maps RPC program and version numbers to transport-specific port numbers. This 
program makes dynamic binding of remote programs possible. This is desirable because the range of 
reserved port numbers is very small and the number of potential remote programs is very large. By running 
only the port mapper on a reserved port, the port numbers of other remote programs can be ascertained by 
querying the port mapper. The port mapper also aids in broadcast RPC. A given RPC program will usually 
have different port number bindings on different machines, so there is no way to directly broadcast to all of 
these programs. The port mapper, however, does have a fixed port number. So, to broadcast to a given 
program, the client actually sends its message to the port mapper located at the broadcast address. Each port 
mapper that picks up the broadcast then calls the local service specified by the client. When the port mapper 
gets the reply from the local service, it sends the reply on back to the client. 

PortMapper Protocol Specification (in RPC Language) 

const PMAP^PORT =111;/* portmapper port number */ 

A mapping of (program, version, protocol) to port number: 

struct mapping { unsigned int prog; unsigned int vers; unsigned int prot; unsigned int port; ); 
Supported values for the "prot" field: 

const IPPROTO_TCP = 6; /* protocol number for TCP/IP */ const IPPROTO.UDP = 17; /* protocol 
number for UDP/IP */ A list of mappings: struct *pmaplist { mapping map; pmaplist next; }; 

Arguments to callit: struct calLargs { unsigned int prog; unsigned int vers; unsigned int proc; opaque 
argso; }; Results of callit: struct calLresult { unsigned int port; opaque reso; }; Port mapper procedures: 
program PMAP_PROG { version PMAP.VERS { void PMAPPROC_NULL(void) = 0; bool 
PMAPPROC^SET(mapping) = 1 ; bool PMAPPROC_UNSET(mapping) = 2; unsigned int 
PMAPPROC_GETPORT(mapping) = 3; pmaplist PMAPPROC_DUMP(void) = 4; calLresult 
PMAPPROC^CALLIT(calLargs) = 5; ) = 2; } = 100000; 
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11.3.3 Port Mapper Operation 

The portmapper program currently supports two protocols (UDP and TCP), The portmapper is contacted by 
talking to it on assigned port number 1 1 1 (SUNRPC) on either of these protocols. The following is a 
description of each of the portmapper procedures: PMAPPROC.NULL: This procedure does no work. By 
convention, procedure zero of any protocol takes no parameters and returns no results. 

PMAPPROC^SET: When a program first becomes available on a machine, it registers itself with the port 
mapper program on the same machine. The program passes its program number "prog", version number 
"vers", transport protocol number "prot". and the port "port" on which it awaits service request. The 
procedure returns a boolean reply whose value is "TRUE" if the procedure successfully established the 
mapping and "FALSE" otherwise. The procedure refuses to establish a mapping if one already exists for the 
tuple "(prog, vers. prot)". 

PMAPPROC_UNSET: When a program becomes unavailable, it should unregister itself with the port 

mapper program on the same machine. The parameters and results have meanings identical to those of 
"PMAPPROC_SET". The protocol and port number fields of the argument are ignored. 

PMAPPROC_GETPORT: Given a program number "prog", version number "vers", and transport protocol 
number "prot", this procedure returns the port number on which the program is awaiting call requests. A 
port value of zeros means the program has not been registered. The "port" field of the argument is ignored. 
PMAPPROC_DUMP: This procedure enumerates all entries in the port mapper's database. The procedure 
takes no parameters and returns a list of program, version, protocol, and port values. 
PMAPPROC_CALLIT: This procedure allows a client to call another remote procedure on the same 
machine without knowing the remote procedure's port number. It is intended for supporting broadcasts to 
arbitrary remote programs via the well-known port mapper's port. The parameters "prog", "vers", "proc", 
and the bytes of "args" are the program number, version number, procedure number, and parameters of the 
remote procedure. Note: (1) This procedure only sends a reply if the procedure was successfully executed 
and is silent (no reply) otherwise. (2) The port mapper communicates with the remote program using UDP 
only. The procedure returns the remote program's port number, and the reply is the reply of the remote 
procedure. 

11.3.4 Service Announcement 

Service announcement method of the application recognition is very similar to server announcement. One 
specific difference in service announcement is that the announcements are made regularly and contain fixed 
information. Also, service announcement based applications only provide the key information for locating 
applications in each announcement. There is no capability to request a specific service. Each client must 
learn the key information required to access an application. 

Novell's IPX SAP is a good example of service announcement oriented communications process. A Novell 
server will have many different services, which it may provide to clients on network. IPX uses service 
access points or SAP as a way to identify specific applications and services. 

11.3.5 In-stream Recognition and Extraction 

The process of identifying more of the business applications on networks today requires analysis of 
information in stream of the network data. Simply, this means that in order to contain the visibility to 
application traffic flow, a process must routinely analyze the network stream itself 

SMB is a protocol used to in networks today which has textual information during the data exchange that 
can be used to further determine the type of end-user application involved in communications. An SMB 
packet is usually transported above the NetBIOS session protocol. Inside the SMB header is a function 
code. This function code is one octet in length and assists in the classification of the type of SMB data in 
the payload. 

11.3.5.1 Web-based Applications 

The best example of applications requiring in-stream recognition mainly Web-based. These applications 
generally utilize two well-known ports for all conversations. Because of this, they can be considered 
multiplex ports. There is one big difference, the client and server have no well-known exchange mechanism 
outside of the normal data stream. Therefore, these applications require combining session tracking and in 
stream recognition to derive end-user application. 
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As discussed earlier, point cast is one of the most widely used Web based application. The steps required to 
detail point cast can be rid repeated for other Web based applications. This is also a good example for 
understanding the process used in combining session tracking with other recognition techniques. 

The process begins when a client Web the browser initiates a request to a point cast Web server. This 
request 
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1 introduction 



This document describes the methodology to be used to build testbenches for the MeterRow Accelerator 
Modules Verilog and VHDL implementations. The goal is to have fully automated testing. This means 
that the unit under tests (UUT) output is compared to expected data generated by the C model and the 
results can be reported as pass/fail. The input to the testbenches are files generated by the MeterFlow 
Compiler. 

1. 1 Technically Elite MeterFlow Accelerator Modules Testbench 

• Written in both the Verilog and VHDL 

• Asynchronous interfaces each have a separate clock 

• Automated testing and result reporting 

• The same input files read by the testbenches and the C model 
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2 Test Flow Chart 
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2.1 Test Flow Chart Description 

The MeterFlow Compiler takes as it's input three sets of files. The first is the Protocol List file. This file 
describes the protocols this implementation of the hardware must recognize and process. The compiler 
will then lookup each of the protocols in the list for their Packet Description Language file. Each of these 
files describes how to recognize and process the protocol. Finally the compiler may be given a Hardware 
Description files that specifies the hardware resources available for this implementation. The compiler can 
also generate this file by determining the minimum resources required to implement all the protocols in 
the list. 

The compiler outputs the databases used by the MeterFlow accelerator. These databases can be read into 
the C model, the UUT and the actual hardware (if it exists). It also outputs a set of input stimulus files for 
both the C model and the testbenches. 

The C model emulates the functions of the UUT and produces expected data files. These files contain 
cycle by cycle data that the testbench uses to check the results of the test. 
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3 Testbench Block Diagram 



Clock and Reset Process 



CPU Input Stimulus 



DataPort Stimulus 



CPU Input Interface 
Process 



SD/SGRAM Memory 
Process 



< ► 



-Slart- 



DataPort Interface Process 



Databases 



Unit Under Test 



Start 




Technically Elite MeterFlow Accelerator Modules Testbench Specification 
Confidential Page 5 of 6 



Technically Elite 



CONFIDENTIAL 



3. 1 Testbench Block Diagram Description 

The testbenches are built up of separate processes run concurrently. The Clock and Reset Process 
generates the system clock and system reset signals. If a process requires a different clock, such as the 
SD/SGRAM Memory Process, it generates that clock itself. 

The SD/SGRAM Memory Process instantiates the target memory the system is to use. An accurate model 
of the memory is required to assure valid results. 

The three processes that are shown importing files, each instantiate memories to hold the data read from 
the files. These memories act as patterns to be either driven into the UUT or patterns the output of the 
UUT are compared against. Since the UUT must be programmed before testing can begin, there is a 
handshake between each of the three processes. This is shown in the diagram as the Start signals. 

The test begins with the CPU Input Interface Process programming the UUT. Once the UUT is 
programmed, the CPU Input Interface Process raises it's Start output. This tells the DataPort Interface 
Process to begin sending packets into the UUT. After the packets are completed the DataPort Interface 
Process raises it's Start output. The CPU Output Interface Process then begins reading the flow database. 
It checks the flows against the expected data and writes the Test Results file. 
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Exhibit B2: The first page of file big.cpl. 

The cpl files (big.cpl, bigfgc3.cpl, bigfgpc.cpl, bigfpayl.cpl, bigfpayl2.cpl, 
bigfpgrp.cpl, bigfpgrp2.cpl, bigfrag.cpl, bigfrag2.cpl, output.cpl, Protocols.cpl, 
short.cpl, shrtfpg2.cpl, shrtfpsS.cpl, shrtfps4,cpl, shrtfpsS.cpl, shrttunl.cpl) are files 
for the protocol compiler of all the actual protocols recognized by the system. These 
files include a description of the parser information for the parser to perform the 
parsing/extracting operation according to the protocol. They also contain the state 
processing states for the state operations of elements (d) and (e) of claim 54. The 
first page of one file is provided. 



Gener-ated on ||Hm[[|||B|9 22 : 04 : 05 

OxOlTC — Total number o£ protocols (380 dec) 



— Virtual Layer Decodes 

**************************************************************************** 

VirtualBase Text Name 



0x00 





InternalProtocolCode 




0x01 





HeaderLengthFixed (0x00 - no [computed], 0x01 - yes 


[fixed]) 


0x00 


_ _ 


HeaderLengthElementSize (0x00 - byte, 0x01 nibble) 




0x00 





HeaderLengthWord (0x00 - byte count, 0x01 word count 


(32 bits)) 


0x01 




HeaderLengthField (byte offset or nibble offset) 




0x00 


- — 


DLCLayerFlag ( NO ) 




0x00 


_ _ 


DLCLayerDes toff set ( NULL ) 




0x00 




DLCLayerDestMask ( NULL ) 




0x00 


_ ^ 


DLCLayerSrcOf fset ( NULL ) 




0x00 




DLCLayerSrcMask ( NULL ) 




0x00 




NetLayerFlag ( NO ) 




0x00 




NetLayerAddressSize ( NULL ) 




0x00 





NetLayerDestOf fset ( NULL ) 




0x00 




NetLayerDestMask ( NULL ) 




0x00 




NetLayerSrcOf f set ( NULL ) 




0x00 




NetLayerSrcMask ( NULL ) 




0x00 




Net Layer Fragments ( NULL ) 




0x00 




TunnelLayerFlag ( NO ) 




0x00 




TunnelLayerAddressSize ( NULL ) 




0x00 




TuzmelLayerDestOf fset ( NULL ) 




0x00 




TuxmelLayerDestMask ( NULL ) 




0x00 




TunnelLayerSrcOf f set ( NULL ) 




0x00 




TunnelLayerSrcMask ( NULL ) 




0x00 




TunnelLayerFragments ( NULL ) 




0x00 




Connec 1 1 onLay e r F 1 ag 




0x00 




ChildRecognitionTypeLengthFlag 




0x01 




ChildRecognitionlgnoreSource (0x00 - no, 0x01 - yes 


[ignore] ) 


0x01 




ChildRecognitionSize 




0x00 




ChildRecognitionDestOf f set 




0x00 




ChildRecognitionSrcOf f set 




0x01 




NumChildren (1 children) 




0x01 


— RecognitionCode 




0x01 


— Ethernet Base 




DLC 


Layer 


Decodes 




— DLC 


(base) Ethernet V2 Decodes 




EtherType — 


Text Name 




0x01 




InternalProtocolCode 




0x01 




HeaderLengthFixed (0x00 - no [computed], 0x01 - yes 


[fixed]) 


0x00 




HeaderLengthElementSize (0x00 - byte, 0x01 nibble) 




0x00 




HeaderLengthWord (0x00 - byte count, 0x01 word count 


(32 bits)) 


OxOE 




HeaderLengthField (byte offset or nibble offset) 




0x01 




DLCLayerFlag ( YES ) 




0x00 




DLCLayerDestOf f set ( 0 - 5 ) 




OxFF 




DLCLayerDestMask ( All bits ) 




0x06 




DLCLayerSrcOf fset ( 6 - 11 ) 





Exhibit B3: The file MFATEST.HEX that contains the actual packets captured by 
the packet acquisition device described in element (a) of claims 1 1 and 54, and 
corresponding to the contents of element (b), the input buffer memory of claim 29. 
The packet acquisition device for the experiment was a SUN workstation connected 
to a connection point of a network. 



42 

08 00 20 13 10 D2 00 AO 24 75 C7 78 08 00 45 00 

00 30 BO 6C 40 00 80 06 94 14 59 06 06 03 59 07 

FE 36 09 53 00 6E lA 5D 8A 6E 50 DA 49 60 50 18 

ID 4B BF 97 00 00 52 45 54 52 20 32 OD OA FD 6E 

9D F5 

*-*_*_*_*-*-*-*-*-*-*-*-♦-*-*-*-*-*-*-*-*-*-*-*-* 

00 00 00 00 08 00 20 13 10 D2 00 AO 24 75 C7 78 

00 08 59 07 FE 36 00 00 00 00 00 00 00 00 00 00 

00 00 59 06 06 03 00 00 00 00 00 00 00 00 00 00 

00 00 00 2B 00 00 00 00 00 00 00 00 00 00 00 00 

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

00 00 00 00 00 00 00 47 00 6E 00 00 09 53 00 00 
*_*_♦_♦_♦.*-*-*-*-*-*-♦-*-*-.*-*-*-♦-*-*-*-*-*-*-* 

4B 

00 AO 24 75 C7 78 08 00 20 13 10 D2 08 00 45 00 

00 39 16 03 00 00 3C 06 B2 75 59 07 FE 36 59 06 

06 03 00 6E 09 53 50 DA 49 60 lA 5D 8A 76 50 18 

10 00 5D 6C 00 00 2B 4F 4B 20 31 33 35 31 20 6F 

63 74 65 74 73 OD OA CA EO 6A Bl 

♦-*-*-*-*-*-*-*-*-*-♦-*-*-*-*-*-*-*-*-*-*-*-*-*-* 

00 00 00 00 00 AO 24 75 C7 78 08 00 20 13 10 D2 

00 08 59 06 06 03 00 00 00 00 00 00 00 00 00 00 

00 00 59 07 FE 36 00 00 00 00 00 00 00 00 00 00 

00 00 00 2B 00 00 00 00 00 00 00 00 00 00 00 00 

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

00 00 00 00 00 00 00 47 09 53 00 00 00 6E 00 00 
*-*_*-*-*-*-*-*-*-*-♦-*-*-*-*-*-*-*-*-*-*-*-*-*-* 

40 

08 00 20 13 10 D2 00 AO 24 75 C7 78 08 00 45 00 
00 28 Bl 6C 40 00 80 06 93 IC 59 06 06 03 59 07 
FE 36 09 53 00 6E lA 5D 8A 76 50 DA 49 71 50 10 
ID 3A 93 73 00 00 00 00 00 00 00 00 02 03 21 C2 
★«*-♦_*_♦-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-♦-*-*-*-* 
00 00 00 00 08 00 20 13 10 D2 00 AO 24 75 C7 78 
00 08 59 07 FE 36 00 00 00 00 00 00 00 00 00 00 
00 00 59 06 06 03 00 00 00 00 00 00 00 00 00 00 
00 00 00 2B 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 47 00 6E 00 00 09 53 00 00 
*-*_*-*-*-*_*_*_*-*-*-*-*-*-*-*-*-*-*-♦-*-*-*-*-* 

22;53:51<0.002> 



TO: 00A02475C778 
FROM: 0800201310D2 



Pkt: 4, Len: 1120/1390 
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TO: 0800201310D2 
FROM: 00A02475C778 



|2:53:51<0.198>1 



Pkt: 5, Len: 64/64 

0000 08 00 20 13 10 D2 00 AO 24 75 C7 78 08 00 45 00 $u.x..E. 

0010 00 28 32 6C 40 00 80 06 92 IC 59 06 06 03 59 07 .(.10 Y...Y. 



0020 FE 36 09 53 00 6E lA 5D 8A 76 50 DA 4E A5 50 10 . 6 .S .n. ] .vP.N.P. 
0030 22 38 89 41 00 00 00 00 00 00 00 00 BA 3C 6B D6 "8.A <k. 



TO: 0800201310D2 
FROM: 00A02475C778 



t:53:53<2.556>1 



Pkt! 6, Len: 66/66 
0000 08 00 20 13 10 D2 00 AO 
0010 00 30 B3 6C 40 00 80 06 
0020 FE 36 09 53 00 6E lA 5D 
0030 22 38 CB 6A 00 00 44 45 
0040 77 D9 



24 75 C7 78 08 00 45 00 

91 14 59 06 06 03 59 07 

8A 76 50 DA 4E A5 50 18 

4C 45 20 32 OD OA BC F6 



• • • • • • • $Vl • X • • E • 
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•6.S.n. } .vP.N.P. 
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06 


03 


00 


6E 


09 


53 


0030 


10 


00 


3F 


4C 


00 


00 


0040 


65 


20 


32 


20 


68 


61 


0050 


65 


74 


65 


64 


2E 


OD 



08 00 20 13 10 D2 08 00 

3C 06 B2 5F 59 07 FE 36 

50 DA 4E A5 lA 5D 8A 7E 

2B 4F 4B 20 4D 65 73 73 

73 20 62 65 65 6E 20 64 

OA 52 E8 E2 05 



45 


00 


• « $u ttX** 


59 


06 


• 1* • • • ^ » • ^_Y « • 6^f • 


50 


18 


. . .n.SP.N. .] .-P. 


61 


67 


..?L..-fOK Messag 


65 


6C 


e 2 has been del 






eted. . .R. • . 



TO: 0800201310D2 
FROM: 00A02475C778 



i2:53:53<0.002> 



Pkt: 8, Len: 64/64 

0000 08 00 20 13 10 D2 

0010 00 2E B4 6C 40 00 

0020 FE 36 09 53 00 6E 

0030 22 17 El 77 00 00 



00 AO 24 75 C7 78 08 00 

80 06 90 16 59 06 06 03 

lA 5D 8A 7E 50 DA 4E C6 

51 55 49 54 OD OA 66 C7 



45 00 $U.X..E. 

59 07 ...1® Y...Y. 

50 18 .6*S.n.] .-P.N.P. 

FO F5 " . .w. .QUIT, .f . . . 



9 TO: 00A02475C778 

FROM: 0800201310D2 



Pkt: 9, Len: 96/96 



0000 


00 


AO 


24 


75 


C7 


78 


08 


00 


20 


13 


10 


D2 


08 


00 


45 


00 


• • $U aX** •••••E« 


0010 


00 


4E 


16 


OA 


00 


00 


3C 


06 


B2 


59 


59 


07 


FE 


36 


59 


06 


.N. . . .<. .YY. .6Y. 


0020 


06 


03 


00 


6£ 


09 


53 


50 


DA 


4E 


C6 


lA 


5D 


8A 


84 


50 


18 


. . .n.SP.N. .3 . .P. 


0030 


10 


00 


AO 


4C 


00 


00 


2B 


4F 


4B 


20 


50 


6F 


70 


20 


73 


65 


. . .L. .-t-OK Pop se 


0040 


72 


76 


65 


72 


20 


61 


74 


20 


73 


75 


70 


65 


72 


20 


73 


69 


rver at super si 


0050 


67 


6E 


69 


6E 


67 


20 


6F 


66 


66 


2E 


OD 


OA 


OD 


7A 


D8 


45 


gnlng o££ • • • • z • E 



10 TO: 00A02475C778 

FROM: 0800201310D2 

Pkt: 10, Len: 64/64 



t:53:53<0*029> 



|22:53:53<0.003> 



0000 00 AO 24 75 C7 78 08 00 20 13 10 D2 08 00 45 00 ..$u.x E. 

0010 00 28 16 OB 00 00 3C 06 B2 7E 59 07 FE 36 59 06 .(....<.. -Y. . 6Y. 

0020 06 03 00 6E 09 53 50 DA 4E EC lA 5D 8A 84 50 11 . . .n. SP .N. . ] . . P . 

0030 10 00 9B 23 00 00 00 00 00 00 00 00 2B A5 6E 6A ...# •t-.nj 



11 TO: 0800201310D2 

PROM: 00A02475C778 



t:53:53<0.000> 



Pkt: 11, Len: 64/64 

0000 08 00 20 13 10 D2 00 AO 

0010 00 28 B5 6C 40 00 80 06 

0020 FE 36 09 53 00 6E lA 5D 

0030 21 Fl 89 32 00 00 00 00 



24 75 C7 78 08 00 45 00 
8P IC 59 06 06 03 59 07 
8A 84 50 DA 4E ED 50 10 
00 00 00 00 BA 06 A9 CC 



• • « • • • • $u • X • • E • 

• (•19a**** Y • • * Y • 

.6.S.n* ] . .P*N«P. 
I . .2 



12 TO: 0800201310D2 ^^^^PR : 53 : 53<0 . 031> { 

FROM: 00A02475C778 

Pkt: 12, Len: 64/64 

0000 08 00 20 13 10 D2 00 AO 24 75 C7 78 08 00 45 00 $u*x. .E. 

0010 00 28 B6 6C 40 00 80 06 8E IC 59 06 06 03 59 07 .(.10 Y. . .Y. 

0020 FE 36 09 53 00 6E lA 5D 8A 84 50 DA 4E ED 50 11 . 6 .S .n. ] . .P.N.P. 

0030 21 Fl 89 31 00 00 00 00 00 00 00 00 IC BC F9 85 !••! 




13 TO: OOA02475C778 |^^PHi22 : 53 : 53<0 * 001> 

FROM: 0800201310D2 ^ %\ 

Pkt: 13, Len: 64/64 

0000 00 AO 24 75 C7 78 08 00 20 13 10 D2 08 00 45 00 ..$u.x E. 

0010 00 28 16 OC 00 00 3C 06 B2 7D 59 07 FE 36 59 06 .(••••<.. }Y. . 6Y. 

0020 06 03 00 6E 09 53 50 DA 4E ED lA 5D 8A 85 50 10 • * .n* SP .N. . ] . . P . 

0030 10 00 9B 22 00 00 00 00 00 00 00 00 EO F4 BC BO 



14 TO: 006008COD710 

FROM: OOA076A010F2 



s53:58<4.755> 



Pkt: 14, Len: 64/64 

0000 00 60 08 CO D7 10 00 AO 

0010 00 2C 5F FE 40 00 80 06 

0020 17 18 05 B4 00 8B 01 BE 

0030 20 00 53 E9 00 00 02 04 



76 AO 10 F2 08 00 45 00 
B9 OB 59 59 18 06 59 4B 
3A 7E 00 00 00 00 60 02 
05 B4 20 00 D9 FB 20 4D 



.0. • 



.V E. 

. . .YY. •YK 



15 TO: 00A076A010F2 

FROM: 006008C0D710 

Pkt: 15, Len: 64/64 

0000 00 AO 76 AO 10 F2 00 60 08 CO D7 10 08 00 45 00 , .v. .E. 

0010 00 2C 49 7C 40 00 80 06 CF 8D 59 4B 17 18 59 59 .,l|0 YK* .YY 

0020 18 06 00 8B 05 B4 IE CD 51 3B 01 BE 3A 7F 60 12 Q; . * : . ^ * 




Exhibit B4: The file packets.txt that describes the nature of the packets 
MFATEST.HEX. 



packets, txt 



***** Packet ID: 1 ***** 

ETHERNET================================:=== 

Destination Address: 080020-1310d2 (super) 
Source Address: 006097 -QdGbld (embedded-pc) 
Ethernet Type: 08-00 (IP) 

Version: 4 

Header Length: 5 (0x5) 

Type of service: 00 

TOS Precedence: Routine (0) 

TOS Delay: Normal Del ay (0) 

TOS Throughput: Normal Throughput (0) 

TOS Reliability: Normal Reliability(O) 

Total Length: 44 (0x2 c) 

Identification: 56918 (0xde56) 

Reserved: 0 

Don't Fragment (DF): Don't Fragment (1) 

More Fragment (MF): Last Fragment (0) 

Fragment Offset: 0 

Time to Live (TTL): 32 (0x20) 

Protocol: TCP (6) 

Header checksum: 7B B5 

Source IP: 89.76.80.54 (embedded-pc) 

Destination IP: 89.7.254.54 (super) 

TCp:========================================= 

Source Port: (1427) 

Destination Port: pop3(110) 

Sequence Number: 16058242 (Oxf 50782) 

Acknowledgement Number: 0 

Data Offset: 6 (0x6) 

Reserved: 0 

urgent Field (URG): 0 

Acknowledgement field (ACK): 0 

Push Function (PSH): 0 

Reset connection (RST): 0 

synchronize sequence (SYN): 1 

NO More Data (fin): 0 

window Size: 8192 (0x2000) 

checksum: 68 EE 

Urgent Pointer: 0 



***** Packet ID: 2 ***** 

ETHERNET========^^=:=====^=============='=======^:=====^^^ 

Destination Address: 006097'9d6bld (embedded-pc) 
Source Address: 080020''1310d2 (super) 
Ethernet Type: 08-00 (IP) 

Version: 4 

Header Length: 5 (0x5) 

Type of service: 00 

TOS Precedence: Routine (0) 

TOS Delay: Normal Del ay (0) 

TOS Throughput: Normal Throughput (0) 

TOS Reliability: Normal Reliability(O) 

Total Length: 44 (0x2 c) 

Identification: 1630 (0x65e) 

Reserved: 0 

Don't Fragment (DF): May Fragment (0) 
More Fragment (MF): Last Fragment (0) 
Fragment Offset: 0 
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Time to Live (ttl): 60 C0x3c) 
Protocol: TCP (6) 
Header Checksum: 77 AE 
source IP: 89.7.254.54 (super) 
Destination IP: 89.76.80.54 (embedded -pc) 

TCP=====================~~=================== 

Source Port: POP3(110) 

Destination Port: (1427) 

Sequence Number: 1240192000 (0x49ebd400) 

Acknowledgement Number: 16058243 (Ox f 50783) 

Data Offset: 6 (0x6) 

Reserved: 0 

urgent Field (URG): 0 

Acknowledgement field (ACK): 1 

Push Function (PSH): 0 

Reset Connection (RST): 0 

Synchronize Sequence (SYN): 1 

No More Data (FIN): 0 

Window Size: 4096 (0x1000) 

checksum: 5a f1 

Urgent Pointer: 0 



***** Packet ID: 3 

ETHERNET===:^======r=====:===r===^^:=================^==:====:===^^ 

Destination Address: 080020-1310d2 (super) 
Source Address: 006097'9d6bld (embedded-pc) 
Ethernet Type: 08-00 (IP) 

Version: 4 

Header Length: 5 (0x5) 

Type of Service: 00 

TOS Precedence: Routine (0) 

TOS Delay: Normal Del ay (0) 

TOS Throuqhput: Normal Throughput (0) 

TOS Reliability: Normal Reliability(O) 

Total Length: 40 (0x28) 

Identification: 57174 (0xdf56) 

Reserved: 0 

Don't Fragment (df): Don't Fragment (1) 

More Fragment (mf): Last Fragment (0) 

Fragment offset: 0 

Time to Live (TTL): 32 (0x20) 

Protocol: TCP (6) 

Header checksum: 7A B9 

source IP: 89.76.80,54 (embedded-pc) 

Destination IP: 89.7.254.54 (super) 

Source Port: (1427) 

Destination Port: pop3(110) 

sequence Number: 16058243 (Oxf 50783) 

Acknowledgement Number: 1240192001 (0x49ebd401) 

Data Offset: 5 (0x5) 

Reserved: 0 

Urqent Field (URG): 0 

Acknowledgement field (ACK): 1 

Push Function (PSH): 0 

Reset connection (RST): 0 

Synchronize Sequence (SYN): 0 

NO More Data (fin): 0 

Window Size: 8760 (0x2238) 

Checksum: 60 76 

Urgent Pointer: 0 
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***** packet ID 
ETHERNET- 



Destination Address: 006097'9d6bld (embedded-pc) 
source Address: 080020-1310d2 (super) 
Ethernet Type: 08-00 (IP) 

version: 4 

Header Length: 5 (0x5) 

Type of service: 00 

TOS Precedence: Routine(O) 

TOS Delay: Normal Del ay (0) 

TOS Throughput: Normal Throughput (0) 

TOS Reliability: Normal Reliability(O) 

Total Length: 120 (0x78) 

Identification: 1649 (0x671) 

Reserved: 0 

Don't Fragment (DF): May Fragment (0) 
More Fragment (mf): Last Fragment(O) 
Fragment offset: 0 
Time to Live (TTL): 60 (0x3c) 
protocol: TCP (6) 
Header checksum: 77 4F 
source IP: 89.7.254.54 (super) 
Destination IP: 89.76.80.54 (embedded-pc) 
TCP='^ 



source Port: POPS (110) 

Destination Port: (1427) 

sequence Number: 1240192001 (0x49ebd401) 

Acknowledgement Number: 16058243 (0xf50783) 

Data Offset: 5 (0x5) 

Reserved: 0 

urgent Field (URG): 0 

Acknowledgement field (ACK): 1 

Push Function (PSH): 1 

Reset connection (RST): 0 

synchronize sequence (SYN): 0 

No More Data (fin): 0 

window size: 4096 (0x1000) 

checksum: BA 88 

urgent Pointer: 0 

DA TA======^===^================================='='== 

Data ' 

0000 — 2B 4F 4B 20 51 55 41 4C 43 4F +0K QUALCO 

0010 — 4D 4D 20 50 6F 70 20 73 65 72 MM Pop ser 

0020 — 76 65 72 20 64 65 72 69 76 65 ver derive 

0030 — 64 20 66 72 6F 60 20 55 43 42 d from UCB 

0040 — 20 28 76 65 72 73 69 6F 6E 20 (version 

0050 — 32 2E 31 2E 34 2D 52 33 29 20 2.1.4-R3) 

0060 — 61 74 20 73 75 70 65 72 20 73 at super s 

0070 — 74 61 72 74 69 6E 67 2E OD OA tarting. . . 



***** Packet id: 5 ***** 

ETHERNET^ 



Destination Address: 080020-1310d2 (super) 
source Address: 006097-9d6bld (embedded-pc) 
Ethernet Type: 08-00 (IP) 
IP= 



Version: 4 

Header Length: 5 (0x5) 
Type of Service: 00 

page 3 



packets, txt 

TOS Precedence: Routine(O) 

TOS Delay: Normal Del ay (0) 

TOS Throughput: Normal Throughput (0) 

TOS Reliability: Normal Reliability(O) 

Total Length: 55 (0x37) 

Identification: 57430 (0xe056) 

Reserved: 0 

Don't Fragment (DF): Don't Fragment (1) 

More Fragment (MF): Last Fragment (0) 

Fragment offset: 0 

Time to Live (TTL): 32 (0x20) 

Protocol: TCP (6) 

Header checksum: 79 AA 

Source IP: 89.76,80.54 (embedded-pc) 

Destination IP: 89.7.254.54 (super) 

TCP==========================:====================^ 

source Port: (1427) 

Destination Port: POP3(110) 

sequence Number: 16058243 (Oxf 50783) 

Acknowledgement Number: 1240192081 (0x49ebd451) 

Data Offset: 5 (0x5) 

Reserved: O 

urgent Field (URG): 0 

Acknowledgement field (ACK): 1 

Push Function (PSH): 1 

Reset connection (RST): 0 

Synchronize Sequence (SYN): 0 

NO More Data (fin): 0 

window size: 8680 (0x21e8) 

checksum: E4 02 

urgent Pointer: 0 

Data: 

0000 55 53 45 52 20 6A 6d 61 69 78 USER jmaix 
0010 6e 65 72 OD OA ner. . 



***** Packet ID: 6 ***** 

ETHERNET========:===:=^====:=r====^===:==r=====z==zrzz=:=.:==, 

Destination Address: 006097-9d6bld (embedded-pc) 
source Address: 080020-1310d2 (super) 
Ethernet Type: 08'-00 (IP) 

Version: 4 

Header Length: 5 (0x5) 

Type of service: 00 

TOS Precedence: Routine (0) 

TOS Delay: Normal Del ay (0) 

TOS Throughput: Normal Throughput (0) 

TOS Reliability: Normal Reliability(O) 

Total Length: 77 (0x4d) 

Identification: 1650 (0x672) 

Reserved: 0 

Don't Fragment (DF): May Fragment (0) 

More Fragment (MF): Last Fragment(O) 

Fragment Offset: 0 

Time to Live (TTL): 60 (Ox 3c) 

Protocol: TCP (6) 

Header checksum: 77 79 

source IP: 89.7.254.54 (super) 

Destination IP: 89.76.80.54 (embedded-pc) 

rcp=^===================:=======^====:^============= 

source Port: pop3(110) 
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Destination Port: (1427) 

sequence Number: 1240192081 (0x49ebd451) 

Acknowledgement Number: 16058258 (0xf50792) 

Data Offset: 5 (0x5) 

Reserved: 0 

urgent Field (URG): 0 

Acknowledgement field (ACK): 1 

Push Function (psh): 1 

Reset connection (RST): 0 

synchronize Sequence (SYN): 0 

NO More Data (FIN): 0 

window size: 4096 (0x1000) 

Checksum: Cl E2 

urgent Pointer: 0 

DA TA=============================================^ 

Data: 

0000 — 2B 4F 4B 20 50 61 73 73 77 6F +0K Passwo 

0010 — 72 64 20 72 65 71 75 69 72 65 rd require 

0020 — 64 20 66 6F 72 20 6A 6D 61 69 d for jmai 

0030 — 78 6E 65 72 2E Od Oa xner. . . 



***** Packet ID: 7 ***** 

Destination Address: '080020-1310d2 (super) 
Source Address: 006097-9d6bld (embedded-pc) 
Ethernet Type: 08-00 (IP) 

version: 4 

Header Length: 5 (0x5) 

Type of Service: 00 

TOS Precedence: Routine(O) 

TOS Delay: Normal Del ay (0) 

TOS Throughput: Normal Throughput (0) 

TOS Reliability: Normal Reliability(O) 

Total Length: 55 (0x37) 

Identification: 57686 (0xel56) 

Reserved: 0 

Don't Fragment (df): Don't Fragment (1) 

More Fragment (MF) : Last Fragment (0) 

Fragment Offset: 0 

Time to Live (TTL): 32 (0x20) 

Protocol: TCP (6) 

Header Checksum: 78 AA 

source IP: 89.76.80.54 (embedded- pc) 

Destination IP: 89.7.254.54 (super) 

TCP=======================================================^^ 

Source Port: (1427) 

Destination Port: pop3(110) 

Sequence Number: 16058258 (Oxf 50792) 

Acknowledgement Number: 1240192118 (0x49ebd476) 

Data offset: 5 (0x5) 

Reserved: 0 

urgent Field (URG): 0 

Acknowledgement field (ACK): 1 

Push Function (psh): 1 

Reset Connection (RST): 0 

Synchronize Sequence (SYN): 0 

No More Data (fin): 0 

window Size: 8643 (0x2 lc3) 

Checksum: db 04 

Urgent Pointer: 0 

DATA=======^=====^==^=========^=====^=====^==^^=^=='=======^^ 
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Data: 

0000 — 50 41 53 53 20 6A 6D 61 69 78 PASS imaix 
0010 — 6E 65 72 OD OA ner. . 



***** Packet id: 8 ***** 

Destination Address: 006097'9d6bld (embedded-pc) 
Source Address: 080020- 1310d2 (super) 
Ethernet Type: 08-00 (IP) 

version: 4 

Header Length: 5 (0x5) 

Type of service: 00 

TOS Precedence: Routine (0) 

TOS Delay: Normal Del ay (0) 

TOS Throughput: Normal Throughput (0) 

TOS Reliability: Normal Reliability(O) 

Total Length: 40 (0x28) 

Identification: 1651 (0x673) 

Reserved: 0 

Don't Fragment (DF): May Fragment (0) 

More Fragment (MF): Last Fragment (0) 

Fragment offset: 0 

Time to Live (TTL) : 60 (0x3 c) 

Protocol: TCP (6) 

Header checksum: 77 9D 

Source IP: 89.7.254.54 (super) 

Destination IP: 89.76.80.54 (embedded-pc) 

source Port: P0P3(110) 

Destination Port: (1427) 

sequence Number: 1240192118 (0x49ebd476) 

Acknowledgement Number: 16058273 (0xf507al) 

Data offset: 5 (0x5) 

Reserved: 0 

Urgent Field (URG): 0 

Acknowledgement field (ACK): 1 

Push Function (PSH): 0 

Reset connection (RST): 0 

Synchronize Sequence (SYN): 0 

No More Data (FIN): 0 

window Size: 4096 (0x1000) 

Checksum: 72 IB 

Urgent Pointer: 0 



***** Packet ID: 9 

ETHERNET===:=====:=======================:^=:===:r:=,==: 

Destination Address: 006097'9d6bld (embedded-pc) 
Source Address: 080020-1310d2 (super) 
Ethernet Type: 08-00 (IP) 

Version: 4 

Header Length: 5 (0x5) 

Type of service: 00 

TOS Precedence: Routine(O) 

TOS Delay: Normal Del ay (0) 

TOS Throughput: Norma/ Throughput (0) 

TOS Reliability: Normal Reliability(O) 

Total Length: 83 (0x53) 

Identification: 1654 (0x676) 

Reserved: 0 

Page 6 



packets, txt 
Don't Fragment (DF): May Fragment (0) 
More Fragment (MF): Last Fragment(O) 
Fragment Offset: 0 
Time to Live (TTL): 60 (Ox 3c) 
Protocol: TCP (6) 
Header checksum: 77 6F 
source IP: 89.7.254.54 (super) 
Destination IP: 89.76.80.54 (embedded-pc) 

source Port: POP3(110) 

Destination Port: (1427) 

sequence Number: 1240192118 (0x49ebd476) 

Acknowledgement Number: 16058273 (0xf507al) 

Data offset: 5 (0x5) 

Reserved: 0 

urgent Field (URG): 0 

Acknowledgement field (ack): 1 

Push Function (PSH): 1 

Reset Connection (RST): 0 

synchronize Sequence (SYN): 0 

No More Data (fin): 0 

Window Size: 4096 (0x1000) 

checksum: 40 BC 

Urgent Pointer: 0 

DA TA=================^============^================= 

Data: 

0000 — 28 4F 4B 20 6a 6D 61 69 78 6e +OK jmaixn 
0010 " 65 72 20 68 61 73 20 30 20 6D er has 0 m' 
0020 — 65 73 73 61 67 65 28 73 29 20 essage(s) 
0030 — 28 30 20 6F 63 74 65 74 73 29 (0 octets) 
0040 " 2E OD OA 



***** Packet id: 10 ***** 

Destination Address: 080020-1310d2 "(super) 
source Address: 006097-9d6bld (embedded-pc) 
Ethernet Type: 08-00 (IP) 

version: 4 

Header Length: 5 (0x5) 

Type of service: 00 

TOS Precedence: Routine (0) 

TOS Delay: Normal Del ay (0) 

TOS Throughput: Normal Throughput (0) 

TOS Reliability: Normal Reliability(O) 

Total Length: 46 (0x2e) 

Identification: 57942 (0xe256) 

Reserved: 0 

Don't Fragment (DF): Don't Fragment (1) 

More Fragment (MF): Last Fragment (0) 

Fragment Offset: 0 

Time to Live (TTL): 32 (0x20) 

Protocol: TCP (6) 

Header checksum: 77 B3 

source IP: 89.76.80.54 (embedded-pc) 

Destination IP: 89.7.254.54 (super) ^ 

Source Port: (1427) 
Destination Port: POP3(110) 
sequence Number: 16058273 (0xf507al) 
Acknowledgement Number: 1240192161 (0x49ebd4al) 
Data offset: 5 (0x5) 
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Reserved: 0 
urgent Field (URG): 0 
Acknowledgement field (ack). 
Push Function (psh): 1 
Reset connection (rst): 0 
Synchronize Sequence (SYN): 
No More Data (fin): 0 
window size: 8600 (0x2198) 
checksum: BE 97 
urgent Pointer: 0 

DA TA==~=====:======:=:====rT==z 



packets, txt 



Data: 53 54 41 54 OD OA STAT. . 



***** Packet ID: 11 ***** 
ETHERNET:=^ 



Destination Address: 006097'9d6bld (embedded-pc) 
source Address: 080020- 1310d2 (super) 
Ethernet Type: 08-00 (IP) 

Version: 4 



Header Length: 5 (0x5) 

Type of service: 00 

TOS Precedence: Routine(O) 

TOS Delay: Normal Del ay (0) 

TOS Throughput: Normal Throughput (0) 

TOS Reliability: Normal Reliability(O) 

Total Length: 49 (0x31) 

Identification: 1655 (0x677) 

Reserved: 0 

Don't Fragment (DF): May Fragment (0) 
More Fragment (MF): Last Fragment (0) 
Fragment offset: 0 
Time to Live (TTL): 60 (0x3c) 
Protocol: TCP (6) 
Header checksum: 77 90 
source IP: 89.7.254.54 (super) 
Destination IP: 89.76.80.54 (embedded-pc) 

TCP====:=====^ 



Source Port: POP3(110) 

Destination Port: (1427) 

sequence Number: 1240192161 (0x49ebd4al) 

Acknowledgement Number: 16058279 (0xf507a7) 

Data Offset: 5 (0x5) 

Reserved: 0 

urgent Field (URG): 0 

Acknowledgement field (ACK): 1 

Push Function (PSH): 1 

Reset connection (RST): 0 

Synchronize Sequence (SYN): 0 

No More Data (FIN): 0 

Window Size: 4096 (0x1000) 

Checksum: 91 3C 

Urgent Pointer: 0 

DATAz 



Data: 2B 4F 4B 20 30 20 30 OD OA +OK 0 0. 



***** Packet ID: 12 ***** 

ETHERNET^ 



Destination Address: 080020'1310d2 (super) 
source Address: 006097-9d6bld (embedded-pc) 
Ethernet Type: 08-00 (IP) 
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Version: 4 

Header Length: 5 (0x5) 

Type of Service: 00 

TOS Precedence: Routine (0) 

TOS Delay: Normal Del ay (0) 

TOS Throughput: Normal Throughput (0) 

TOS Reliability: Normal Reliability(O) 

Total Length: 46 (0x2e) 

Identification: 58198 (0xe356) 

Reserved: 0 

Don't Fragment (DF): Don't Fragment (1) 

More Fragment (MF): Last Fragment (0) 

Fragment offset: 0 

Time to Live (TTL): 32 (0x20) 

Protocol: TCP (6) 

Header checksum: 76 B3 

Source IP: 89.76.80.54 (embedded-pc) 

Destination IP: 89.7.254.54 (super) 

rCP========:===:=========:==========:===========:==== 

Source Port: (1427) 

Destination Port: pop3(110) 

sequence Number: 16058279 (0xf507a7) 

Acknowledgement Number: 1240192170 (0x49ebd4aa) 

Data offset: 5 (0x5) 

Reserved: 0 

Urgent Field (URG): 0 

Acknowledgement field (ACK): 1 

Push Function (PSH): 1 

Reset Connection (RST): 0 

Synchronize Sequence (SYN): 0 

NO More Data (FIN): 0 

window Size: 8591 (0x218f) 

Checksum: b8 90 

Urgent Pointer: 0 

DA TA=======================:===============:=====:. 

Data: 51 55 49 54 OD OA QUIT. . 



***** Packet ID: 13 ***** 

ETHERNET=^==^=====^==:^=^======r=:============;;====:==== 

Destination Address: 006097- 9d6bld (embedded-pc) 
Source Address: 080020-1310d2 (super) 
Ethernet Type: 08-00 (IP) 

version: 4 

Header Length: 5 (0x5) 

Type of service: 00 

TOS Precedence: Routine (0) 

TOS Delay: Normal Del ay (0) 

TOS Throughput: Normal Throughput (0) 

TOS Reliability: Normal Reliability(O) 

Total Length: 78 (0x4e) 

Identification: 1656 (0x678) 

Reserved: 0 

Don't Fragment (DF): May Fragment (0) 

More Fragment (MF): Last Fragment(O) 

Fragment Offset: 0 

Time to Live (ttl): 60 (0x3 c) 

protocol: TCP (6) 

Header checksum: 77 72 

source IP: 89.7.254.54 (super) 

Destination IP: 89.76.80. $4 (embedded-pc) 
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Source Port: POP3(110) 

Destination Port: (1427) 

Sequence Number: 1240192170 C0x49ebd4aa) 

Acknowledgement Number: 16058285 (0xf507ad) 

Data offset: 5 (0x5) 

Reserved: 0 

urgent Field (URG): 0 

Acknowledgement field (ack): 1 

Push Function (psh): 1 

Reset connection (RST): 0 

Synchronize Sequence (SYN): 0 

NO More Data (FIN): 0 

window Size: 4096 (0x1000) 

checksum: 76 DD 

urgent Pointer: 0 

DA TA=================^===^===============^==^========= 

Data: 

0000 — 2B 4F 4B 20 50 6F 70 20 73 65 +0K Pop se 
0010 — 72 76 65 72 20 61 74 20 73 75 rver at su 
0020 ~ 70 65 72 20 73 69 67 6E 69 6E per signin 
0030 ~ 67 20 6F 66 66 2E OD OA g off. . . 



***** Packet ID: 14 

ETHERNET^ 



Destination Address: 080020'1310d2 (super) 
source Address: 006097 '9d6bld (embedded-pc) 
Ethernet Type: 08-00 (IP) 

version: 4 

Header Length: 5 (0x5) 

Type of Service: 00 

TOS Precedence: Routine(O) 

TOS Delay: Normal Del ay (0) 

TOS Throughput: Normal Throughput (0) 

TOS Reliability: Normal Reliability(O) 

Total Length: 40 (0x28) 

Identification: 58454 (0xe456) 

Reserved: 0 

Don't Fragment (DF): Don't Fragment (1) 

More Fragment (MF) : Last Fragment(O) 

Fragment Offset: 0 

Time to Live (TTL): 32 (0x20) 

protocol: TCP (6) 

Header checksum: 75 B9 

Source IP: 89.76.80.54 (embedded-pc) 

Destination IP: 89.7.254.54 (super) 

TCP=~=========================================^ 

Source Port: (1427) 

Destination Port: POP3(110) 

sequence Number: 16058285 (0xf507ad) 

Acknowledgement Number: 1240192208 (0x49ebd4d0) 

Data Offset: 5 (0x5) 

Reserved: 0 

urgent Field (URG): 0 

Acknowledgement field (ACK): 1 

Push Function (PSH): 0 

Reset connection (RST): 0 

Synchronize Sequence (SYN): 0 

NO More Data (fin): 1 

window Size: 8553 (0x2169) 

Checksum: 60 4B 
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***** Packet ID: 15 ***** 

ETHERNET=^ 



Destination Address: OOeogV-gdebld (embedded-pc) 
source Address: 080020- 1310d2 (super) 
Ethernet Type: 08-00 (IP) 



Version: 4 

Header Length: 5 (0x5) 

Type of Service: 00 

Tos Precedence: Routine(O) 

TOS Delay: Normal Del ay (0) 

TOS Throughput: Normal Throughput (0) 

TOS Reliability: Normal Reliability(O) 

Total Length: 40 (0x28) 

Identification: 1657 (0x679) 

Reserved: 0 

Don't Fragment (dp): May Fragment (0) 
More Fragment (MF): Last Fragment (0) 
Fragment Offset: 0 
Time to Live (TTL): 60 (0x3 c) 
Protocol: TCP (6) 
Header Checksum: 77 97 
source IP: 89.7.254.54 (super) 
Destination IP: 89.76.80.54 (embedded-pc) 

TCP======^===^^===^==^^==^=:^:^=r=^^=^rr==J=~. 



source Port: POP3(110) 

Destination Port: (1427) 

Sequence Number: 1240192208 (0x49ebd4d0) 

Acknowledgement Number: 16058286 (0xf507ae) 

Data offset: 5 (0x5) 

Reserved: 0 

Urqent Field (URG): 0 

Acknowledgement field (ack): 1 

Push Function (PSH): 0 

Reset connection (RST): 0 

Synchronize Sequence (SYN): 0 

No More Data (FIN): 0 

window size: 4096 (0x1000) 

checksum: 71 b4 

urgent Pointer: 0 



***** Packet id: 16 ***** 

ETHERNET:^ 



Destination Address: 006097-9d6bld (embedded-pc) 
source Address: 080020-1310d2 (super) 
Ethernet Type: 08-00 (IP) 

version: 4 

Header Length: 5 (0x5) 

Type of service: 00 

TOS Precedence: Routine(O) 

TOS Delay: Normal Del ay (0) 

TOS Throughput: Norma I Throughput (0) 

TOS Reliability: Normal Reliability(O) 

Total Length: 40 (0x28) 

Identification: 1658 (0x6 7a) 

Reserved: 0 

Don't Fragment (DF): May Fragment (0) 
More Fragment (MF): Last Fragment (0) 
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Fragment Offset: 0 

Time to Live (TTL): 60 (0x3 c) 

Protocol: tcp(6) 

Header checksum: 77 96 

source ip: 89.7.254.54 (super) 

Destination IP: 89.76.80.54 (embedded-pc) 

TCP=====^================================^============ 

source Port: POP3(110) 

Destination Port: (1427) 

Sequence Number: 1240192208 (0x49ebd4d0) 

Acknowledgement Number: 16058286 (0xf507ae) 

Data offset: 5 (0x5) 

Reserved: 0 

urgent Field (URG): 0 

Acxnowledgement field (ACK): 1 

Push Function (psh): 0 

Reset connection (rst): 0 

synchronize Sequence (SYN): 0 

NO More Data (FIN): 1 

Window Size: 4096 (0x1000) 

Checksum: 71 b3 

urgent Pointer: 0 



***** Packet id: 17 ***** 

ETHERNET======^^=:==^=====^==^==^===========^^===^===^ 

Destination Address: 080020-1310d2 (super) 
source Address: 006097-9d6bld (embedded-pc) 
Ethernet Type: 08-00 (IP) 

IP=:======:=====:==========================::========-- 

Version: 4 

Header Length: 5 (0x5) 

Type of Service: 00 

TOS Precedence: Routine (0) 

TOS Delay: Normal Del ay (0) 

TOS Throughput: Normal Throughput (0) 

TOS Reliability: Normal Reliability(O) 

Total Length: 40 (0x28) 

Identification: 58710 (0xe556) 

Reserved: 0 

Don't Fragment (DF): Don't Fragment (1) 

More Fragment (MF): Last Fragment (0) 

Fragment offset: 0 

Time to Live (TTL): 32 (0x20) 

Protocol: TCP (6) 

Header checksum: 74 b9 

source IP: 89.76.80.54 (embedded-pc) 

Destination IP: 89.7.254.54 (super) 

TCP=================^=========================='= 

source Port: (1427) 

Destination Port: POP3(110) 

sequence Number: 16058286 (0xf507ae) 

Acknowledgement Number: 1240192209 (0x49ebd4dl) 

Data offset: 5 (0x5) 

Reserved: 0 

urgent Field (urg): 0 

Acknowledgement field (ack): 1 

Push Function (PSH): 0 

Reset connection (rst): 0 

synchronize Sequence (SYN): 0 

No More Data (fin): 0 

window Size: 8553 (0x2169) 

checksum: 60 4A 
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***** packet id: 18 ***** 

Destination Address: 080020'0dddf9 (c3po) 
source Address: 0000a3'b0022a (TecElite-N.b0022a) 
Ethernet Type: 08-00 (IP) 

version: 4 

Header Length: 5 (0x5) 

Type of service: 00 

TOS Precedence: Routine(O) 

TOS Delay: Normal Del ay (0) 

TOS Throughput: Normal Throughput (0) 

TOS Reliability: Normal Reliability(O) 

Total Length: 40 (0x28) 

Identification: 37459 (0x9253) 

Reserved: 0 

Don't Fragment (DF): May Fragment (0) 

More Fragment (MF): Last Fragment (0) 

Fragment offset: 0 

Time to Live (TTL): 61 (0x3d) 

protocol: TCP(6) 

Header checksum: 15 3D 

source IP: 192.190.175.254 (ftp) 

Destination IP: 89.111.12.20 (c3po) 

TCP===================^================================^ 

source Port: telnet(23) 

Destination Port: (32779) 

sequence Number: 3652221321 (0xd9b07989) 

Acknowledgement Number: 4022713487 (0xefc5bc8f) 

Data Offset: 5 (0x5) 

Reserved: 0 

urgent Field (URG): 0 

Acknowledgement field (ACK): 1 

Push Function (PSH): 0 

Reset Connection (RST): 0 

synchronize Sequence (SYN): 0 

NO More Data (FIN): 0 

window size: 32736 (0x7 feO) 

checksum: DA 01 

urgent Pointer: 0 



***** packet ID: 19 ***** 
ETHERNET^ 



Destination Address: 0000a3-b0022a (TecElite-N.b0022a) 
source Address: 080020-0dddf9 (c3po) 
Ethernet Type: 08-00 (IP) 

IP=:======:====================:==============^===============^===^^ 

version: 4 

Header Length: 5 (0x5) 

Type of Service: 00 

TOS Precedence: Routine(O) 

TOS Delay: Normal Del ay (0) 

TOS Throughput: Normal Throughput (0) 

TOS Reliability: Normal Reliability(O) 

Total Length: 40 (0x28) 

Identification: 21585 (0x5451) 

Reserved: 0 

Don't Fragment (DF): Don't Fragment (1) 
More Fragment (mf): Last Fragment (0) 
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Fragment Offset: 0 

Time to Live (TTL): 255 (Oxff) 

Protocol: TCP (6) 

Header checksum: 51 3e 

source IP: 89.111.12.20 (c3po) 

Destination IP: 192.190.175.254 (ftp) 

rcp=============================================- 

source Port: (32779) 

Destination Port: TELNET (2 3) 

sequence Number: 4022713487 (0xefc5bc8f) 

Acknowledgement Number: 3652221322 (0xd9b0798a) 

Data Offset: 5 (0x5) 

Reserved: 0 

urgent Field (UR6): 0 

Acknowledgement field (ACK): 1 

Push Function (PSH): 0 

Reset connection (rst): 0 

Synchronize Sequence (SYN): 0 

No More Data (FIN): 0 

window Size: 8760 (0x2238) 

checksum: 37 A9 

Urgent Pointer: 0 



***** packet id: 20 ***** 



Destination Address: aa0004''000104 (DEC. 000104) 
source Address: 0000e8-061fl5 (smtplink) 
Ethernet Type: 08-00 (IP) 

IP=====r=:================:=====:=================== 

Version: 4 

Header Length: 5 (0x5) 

Type of Service: 00 

TOS Precedence: Routine (0) 

TOS Delay: Normal Del ay (0) 

TOS Throughput: Normal Throughput (0) 

TOS Reliabflity: Normal Reliability(O) 

Total Length: 44 (0x2c) 

Identification: 3736 (0xe98) 

Reserved: 0 

Don't Fragment (DF): May Fragment (0) 

More Fragment (mf): Last Fragment (0) 

Fragment offset: 0 

Time to Live (ttl): 64 (0x40) 

Protocol: TCP (6) 

Header Checksum: 9B OC 

source IP: 89.7.7.100 (smtplink) 

Destination IP: 192.190.175.254 (ftp) 

source Port: (11348) 

Destination Port: SMTP (2 5) 

sequence Number: 104679649 (0x63d48el) 

AcKnowledgement Number: 1 (0x1) 

Data offset: 6 (0x6) 

Reserved: 0 

urgent Field (URG): 0 

Acknowledgement field (ACK): 0 

Push Function (PSH): 0 

Reset Connection (RST): 0 

Synchronize Sequence (SYN): 1 

NO More Data (FIN): 0 

Window Size: 2048 (0x800) 

checksum: 47 OE 
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***** Packet id: 21 ***** 

Destination Address: 0000e8-061fl5 (smtplink) 
Source Address: 0000a3-b0022a (TecElite-N.bOO 
Ethernet Type: 08-00 (IP) 

Version: 4 

Header Length: 5 (0x5) 

Type of Service: 00 

TOS Precedence: Routine (0) 

TOS Delay: Normal Del ay (0) 

TOS Throughput: Normai Throughput (0) 

TOS Reliability: Normal Reliability(O) 

Total Length: 44 (0x2c) 

Identification: 37475 (0x9263) 

Reserved: 0 

Don't Fragment (df): May Fragment (0) 

More Fragment (MF): Last Fragment (0) 

Fragment Offset: 0 

Time to Live (ttl): 62 (0x3e) 

Protocol: TCP(6) 

Header checksum: 19 41 

source IP: 192.190.175.254 (ftp) 

Destination IP: 89.7.7.100 (smtplink) 

TCP===================:=====:===.=====:=:=.==:::,======,, 

Source Port: SMTP(25) 

Destination Port: (11348) 

Sequence Number: 3878102034 (0xe7272412) 

Acknowledgement Number: 104679650 (0x63d48e2) 

Data Offset: 6 (0x6) 

Reserved: 0 

urgent Field (URG): 0 

Acknowledgement field (ACK): 1 

Push Function (PSH): 0 

Reset connection (RST): 0 

synchronize Sequence (SYN): 1 

No More Data (FIN): 0 

window size: 32736 (0x7fe0) 

checksum: C3 £3 

Urgent Pointer: 0 



***** Packet ID: 22 ***** 

ETHERNET=================:=====^===:===,^^=:=:=:^:=„=^::,. 

Destination Address: aa0004-000104 (DEC 000104) 
source Address: 0000e8'061fl5 (smtplink) 
Ethernet Type: 08-00 (IP) 

Version: 4 

Header Length: 5 (0x5) 

Type of service: 00 

TOS Precedence: Routine (0) 

TOS Delay: Normal Del ay (0) 

TOS Throuqhput: Norma 1 Throughput (0) 

TOS Reliability: Normal Reliability(O) 

Total Length: 40 (0x28) 

Identification: 3737 (0xe99) 

Reserved: 0 

Don't Fragment (DF): May Fragment (0) 
More Fragment (MF): Last Fragment (0) 
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Fragment offset: 0 

Time to Live (m): 64 (0x40) 

Protocol: TCP(6) 

Header Checksum: 9b Of 

source IP: 89.7.7,100 (smtplink) 

Destination IP: 192.190.175.254 (ftp) 

rCP================================:======:==========r= 

source Port: (11348) 

Destination Port: SMTP(25) 

sequence Number: 104679650 (0x63d48e2) 

Acknowledgement Number: 3878102035 (0xe7272413) 

Data Offset: 5 (0x5) 

Reserved: 0 

Urgent Field (URG): 0 

Acknowledgement field (ACK): 1 

Push Function (PSH): 0 

Reset connection (rst): 0 

Synchronize Sequence (syn): 0 

NO More Data (fin): 0 

window size: 2048 (0x800) 

Checksum: 4F E5 

Urgent Pointer: 0 



***** Packet id: 23 ***** 

ETHERNET===================::==========:====^========^ 

Destination Address: 0000e8-061fl5 (smtplink) 
source Address: 0000a3-b0022a (TecElite-N.b0022a) 
Ethernet Type: 08-00 (IP) 

version: 4 

Header Length: 5 (0x5) 
Type of service: 00 
TOS Precedence: Routine(O) 
TOS Delay: Normal Del ay (0) 
TOS Throughput: Normal Throughput (0) 
TOS Reliability: Normal Reliability(O) 
Total Length: 44 (0x2c) 
Identification: 37476 (0x9264) 
Reserved: 0 

Don't Fragment (DF): May Fragment (0) 
More Fragment (MF): Last Fragment(O) 
Fragment Offset: 0 
Time to Live (TTL): 62 (0x3 e) 
Protocol: TCP (6) 
Header checksum: 19 40 
Source IP: 192.190.175.254 (ftp) 
Destination IP: 89.7.7.100 (smtplink) 

Source Port: (12998) 
Destination Port: (113) 
Sequence Number: 2356842160 (0x8c7a8eb0) 
Acknowledgement Number: 0 
Data Offset: 6 (0x6) 
Reserved: 0 
urqent Field (URG): 0 
Acxnowledgement field (ACK): 0 
Push Function (PSH): 0 
Reset Connection (RST): 0 
synchronize sequence (SYN): 1 
NO More Data (fin): 0 
window Size: 512 (0x200) 
Checksum: 76 9C 
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***** Packet id: 24 ***** 

ETHERNET=====^=======:===:===^=:=================::^= 

Destination Address: aa0004-000104 (DEC, 000104) 
source Address: 0000e8-061fl5 (smtplink) 
Ethernet Type: 08-00 (IP) 

Version: 4 

Header Length: 5 (0x5) 

Type of service: 00 

TOS Precedence: Routine (0) 

TOS Delay: Normal Del ay (0) 

TOS Throughput: Normal Throughput (0) 

TOS Reliability: Normal Reliability(O) 

Total Length: 40 (0x28) 

Identification: 3738 (0xe9a) 

Reserved: 0 

Don't Fragment (DF): May Fragment (0) 

More Fragment (MF): Last Fragment (0) 

Fragment Offset: 0 

Time to Live (TTL): 64 (0x40) 

Protocol: TCP (6) 

Header checksum: 9b Oe 

Source IP: 89,7.7.100 (smtplink) 

Destination IP: 192.190.175.254 (ftp) 

TCP===================:======::=====================:==::, 

source Port: (113) 
Destination Port: (12998) 
sequence Number: 0 

Acknowledgement Number: 2356842161 (Ox8c7a8ebl) 

Data offset: 5 (0x5) 

Reserved: 0 

Urgent Field (URG): 0 

Acknowledgement field (ACK): 1 

Push Function (PSH): 1 

Reset connection (RST): 1 

synchronize Sequence (SYN): 0 

NO More Data (fin): 0 

window size: 0 

Checksum: 90 3d 

Urgent Pointer: 0 



***** Packet id: 25 ***** 

ETHERNET====:::r::.:=:====::^==:======^==r===,^======::^:=^=r=^::r^= 

Destination Address: 0000e8-061fl5 (smtplink) 
source Address: 0000a3-b0022a (TecElite-N.b0022a) 
Ethernet Type: 08-00 (IP) 

Version: 4 

Header Length: 5 (0x5) 

Type of Service: 00 

TOS Precedence: Routine (0) 

TOS Delay: Normal Del ay (0) 

TOS Throughput: Normal Throughput (0) 

TOS Reliability: Normal Reliability(O) 

Total Length: 125 (0x7d) 

Identification: 37477 (0x9265) 

Reserved: 0 

Don't Fragment (DF): Don't Fragment (1) 
More Fragment (MF): Last Fragment (0) 
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Fragment Offset: 0 

Time to Live (TTL): 62 (0x3 e) 

Protocol: TCP (6) 

Header checksum: D8 ED 

source IP: 192.190.175.254 (ftp) 

Destination IP: 89.7.7.100 (smtplink) 

source Port: SMTP(25) 

Destination Port: (11348) 

sequence Number: 3878102035 (0xe7272413) 

Acknowledgement Number: 104679650 (0x63d48e2) 

Data Offset: 5 (0x5) 

Reserved: 0 

urgent Field (URG): 0 

Acknowledgement field (ACK): 1 

Push Function (PSH): 1 

Reset connection (RST): 0 

Synchronize sequence (SYN): 0 

No More Data (FIN): 0 

window Size: 32736 (0x7 feO) 

checksum: FC 9F 

urgent Pointer: 0 

DATA~========:~=====~==~======~====~===~~~~ 

Da ta : 

0000 " 32 32 30 20 6E 61 74 61 64 6D 220 natadm 

0010 — 2E 74 65 63 65 6C 69 74 65 2E . tecelite. 

0020 — 63 6F 6d 20 45 53 4D 54 50 20 com ESMTP 

0030 — 53 65 6E 64 6D 61 69 6C 20 38 Sendmail 8 

0040 — 2E 38 2E 37 2F 38 2E 38 2E 37 .8.7/8.8.7 

0050 — 3B 20 54 68 75 2C 20 31 30 20 ; Thu, 10 

0060 — 53 65 70 20 31 39 39 38 20 31 Sep 1998 1 

0070 — 37 3A 32 38 3A 31 30 20 2D 30 7:28:10 -0 

0080 " 37 30 30 OD OA 700. . 

***** Packet id: 26 ***** 

ETHERNET=======^=========^====================================== 

Destination Address: aa0004'000104 (DEC. 000104) 
Source Address: 0000e8-061fl5 (smtplink) 
Ethernet Type: 08-00 (IP) 

TP================================================================== 

version: 4 

Header Length: 5 (0x5) 

Type of Service: 00 

TOS Precedence: Routine(O) 

TOS Delay: Normal Del ay (0) 

TOS Throughput: Normal ThrouQhput(O) 

TOS Reliability: Normal Reliability(O) 

Total Length: 68 (0x44) 

Identification: 3739 (0xe9b) 

Reserved: 0 

Don't Fragment (df): May Fragment (0) 

More Fragment (MF): Last Fragment (0) 

Fragment offset: 0 

Time to Live (TTL): 64 (0x40) 

Protocol: TCP (6) 

Header checksum: 9A Fl 

Source IP: 89.7.7.100 (smtplink) 

Destination IP: 192.190.175.254 (ftp) 

Source Port: (11348) 

Destination Port: SMTP (2 5) 

sequence Number: 104679650 (0x63d48e2) 
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Acknowledgement Number: 3878102120 C0xe7272468) 
Data offset: 5 (0x5) 
Reserved: 0 
urqent Field (URG): 0 
Acknowledgement field (ACK): 1 
Push Function (PSH) : 1 
Reset connection (RST): 0 
synchronize Sequence (SYN): 0 
NO More Data (FIN): 0 
window size: 1963 (0x7ab) 
Checksum: 84 C7 
urgent Pointer: 0 

Data: 

0000 48 45 4C 4F 20 73 6D 74 70 6C HELO smtpl 

0010 69 6E 6B 2E 74 65 63 65 6C 69 ink.teceli 

0020 — 74 65 2e 63 6F 6D OD OA te.com. . 



***** Packet id: 27 ***** 

ETHERNET======:====:===:=====^ 



Destination Address: 0000e8'061fl5 (smtplink) 
source Address: 0000a3-b0022a CTecElite-N.b0022a) 
Ethernet Type: 08-00 (IP) 

Version: 4 

Header Length: 5 (0x5) 

Type of Service: 00 

TOS Precedence: Routine(O) 

TOS Delay: Normal Del ay (0) 

TOS Throughput: Normal Throughput (0) 

TOS Reliability: Normal Reliability(O) 

Total Length: 114 (0x72) 

Identification: 37478 (0x9266) 

Reserved: 0 

Don't Fragment (DF): Don't Fragment (1) 

More Fragment (MF): Last Fragment (0) 

Fragment offset: 0 

Time to Live (TTL): 62 (0x3e) 

Protocol: TCP (6) 

Header Checksum: d8 F7 

source IP: 192.190.175.254 (ftp) 

Destination IP: 89.7.7.100 (smtplink) 

source Port: SMTP (2 5) 

Destination Port: (11348) 

sequence Number: 3878102120 (0xe7272468) 

Acknowledgement Number: 104679678 (0x63d48fe) 

Data Offset: 5 (0x5) 

Reserved: 0 

urqent Field (URG): 0 

Acknowledgement field (ACK): 1 

Push Function (PSH): 1 

Reset Connection (rst): 0 

Synchronize Sequence (SYN): 0 

NO More Data (FIN): 0 

window Size: 32736 (Ox7feO) 

Checksum: EA FB 

Urgent Pointer: 0 

DA TA=====^^======^=======:====:========:====:===:==:====~ 

Data: 

0000 — 32 35 30 20 6E 61 74 61 64 6D 250 natadm 
0010 ~ 2E 74 65 63 65 6C 69 74 65 2E . tecelite. 
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0020 — 63 6F 6D 20 48 65 6C 6C 6F 20 com HeJJo 

0030 — 73 6D 74 70 6C 69 6E 6B 20 SB smtplink [ 

0040 — 38 39 2E 37 2E 37 2E 31 30 30 89.7.7.100 

0050 " 5D 2C 20 70 6C 65 61 73 65 64 ], pleased 
0060 — 20 74 6F 20 60 65 65 74 20 79 to meet y 
0070 " 6F 75 Od OA ou. . 



***** Packet ID: 28 

ETHERNET^ 



Destination Address: aa0004-000104 (DEC. 000104) 
Source Address: 0000e8-061fl5 (smtplink) 
Ethernet Type: 08-00 (IP) 



IP=^ 



Version: 4 

Header Length: 5 (0x5) 

Type of service: 00 

TOS Precedence: Routine(O) 

Tos Delay: Normal Del ay (0) 

TOS Throughput: Normal Throughput (0) 

TOS Reliability: Normal Reliability(O) 

Total Length: 88 (0x58) 

Identification: 3740 (0xe9c) 

Reserved: 0 

Don't Fragment (DF): May Fragment (0) 

More Fragment (MF): Last Fragment(O) 

Fragment offset: 0 

Time to Live (TTL): 64 (0x40) 

Protocol: TCP(6) 

Header checksum: 9A DC 

Source IP: 89.7.7.100 (smtplink) 

Destination IP: 192.190.175.254 (ftp) 

Source Port: (11348) 

Destination Port: SMTP(25) 

sequence Number: 104679678 (0x63d48fe) 

Acknowledgement Number: 3878102194 (0xe72724b2) 

Data Offset: 5 (0x5) 

Reserved: 0 

urgent Field (URG): 0 

Acknowledgement field (ACK): 1 

Push Function (PSH): 1 

Reset connection (RST): 0 

Synchronize Sequence (SYN): 0 

NO More Data (fin): 0 

Window size: 1889 (0x761) 

checksum: 68 86 

urgent Pointer: 0 

Data: 
0000 
0010 
0020 
0030 
0040 



4D 41 
3C 44 



49 4C 20 46 52 4F 4D 3A 



6F 75 67 20 46 
65 72 20 3C 64 66 65 
72 40 74 65 63 65 6C 
2e 63 6f 6d 3e 3e OD 



65 6C 64 

6C 64 65 

69 74 65 
OA 



MAIL FROM: 
<Doug Feld 
er <dfelde 
rStecelite 
com». . 



***** packet id: 29 

ETHERNET^ 



Destination Address: 0000e8'061fl5 (smtplink) 
source Address: 0000a3'b0022a (TecElite-N.b0022a) 
Ethernet Type: 08-00 (IP) 
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Version: 4 

Header Length: 5 (0x5) 

Type of Service: 00 

TOS Precedence: Routine(O) 

TOS Delay: Normal Del ay (0) 

TOS Throughput: Norma I Throughput (0) 

TOS Reliability: Normal Reliability(O) 

Total Length: 40 (0x28) 

Identification: 37481 (0x9269) 

Reserved: 0 

Don't Fragment (DF): Don't Fragment (1) 

More Fragment (MF): Last Fragment (0) 

Fragment Offset: 0 

Time to Live (ttl): 62 (0x3 e) 

Protocol: TCP (6) 

Header checksum: D9 3E 

source IP: 192.190.175.254 (ftp) 

Destination IP: 89.7.7.100 (smtplink) 

Source port: SMTP(25) 

Destination Port: (11348) 

Sequence Number: 3878102194 (0xe72724b2) 

Acknowledgement Number: 104679726 (0x63d492e) 

Data Offset: 5 (0x5) 

Reserved: 0 

urqent Field (URG): 0 

Acknowledgement field (ACK): 1 

Push Function (PSH): 0 

Reset connection (rst): 0 

Synchronize Sequence (SYN): 0 

NO More Data (fin): 0 

window size: 32736 (Ox7feO) 

checksum: d7 19 

Urgent Pointer: 0 



***** Packet id: 30 ***** 

Destination Address: 0000e8-061fl5 (smtplink) 
Source Address: 0000a3-b0022a (TecElite-N.b0022a) 
Ethernet Type: 08-00 (IP) 

Version: 4 

Header Length: 5 (0x5) 

Type of Service: 00 

TOS Precedence: Routine(O) 

TOS Delay: Normal Del ay (0) 

TOS Throughput: Normal Throughput (0) 

TOS Reliability: Normal Reliability(O) 

Total Length: 95 (0x5 f) 

Identification: 37482 (0x926a) 

Reserved: 0 

Don't Fragment (DF): Don't Fragment (1) 

More Fragment (MF): Last Fragment (0) 

Fragment Offset: 0 

Time to Live (TTL): 62 (0x3 e) 

Protocol: TCP (6) 

Header Checksum: D9 06 

source IP: 192.190.175.254 (ftp) 

Destination IP: 89.7.7.100 (smtplink) 

TCP===:=============================^===:===^====:=== 

source Port: SMTP(25) 
Destination Port: (11348) 
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packets, txt 
Sequence Number: 3878102194 (0xe72724b2) 
Acknowledgement Number: 104679726 (0x63d492e) 
Data Offset: 5 (0x5) 
Reserved: 0 
urgent Field (URG): 0 
Acknowledgement field (ACK): 1 
Push Function (PSH): 1 
Reset Connection (RST): 0 
Synchronize Sequence (SYN): 0 
NO More Data (fin): 0 
window Size: 32736 (Ox7feO) 
Checksum: DB OA 
Urgent pointer: 0 

DA TA===:========================================:====^ 

Data: 

0000 — 32 35 30 20 3C 44 6F 75 67 20 250 <Doug 

0010 46 65 6C 64 65 72 20 3C 64 66 Felder <df 

0020 — 65 6C 64 65 72 40 74 65 63 65 elder&tece 

0030 — 6C 69 74 65 2E 63 6F 6D 3E 3E lite.com» 

0040 — 2E 2E 2E 20 53 65 6e 64 65 72 ... Sender 
0050 — 20 6F 6b OD Oa ok. . 



jj"**** packet ID: 31 

ETHERNET============:=========r====:=^=^^========:^===- 

Destination Address: aa0004-000104 (DEC 000104) 
Source Address: 0000e8-061fl5 (smtplink) 
Ethernet Type: 08-00 (IP) 
IP=^ 



Version: 4 

Header Length: 5 (0x5) 

Type of Service: 00 

TOS Precedence: Routine(O) 

TOS Delay: Normal Del ay (0) 

TOS Throughput: NormaT Throughput (0) 

TOS Reliability: Normal Reliability(O) 

Total Length: 70 (0x46) 

Identification: 3741 (0xe9d) 

Reserved: 0 

Don't Fragment (DF): May Fragment (0) 

More Fragment (MF): Last Fragment (0) 

Fragment Offset: 0 

Time to Live (TTL): 64 (0x40) 

Protocol: TCP (6) 

Header Checksum: 9a ED 

Source IP: 89.7.7.100 (smtplink) 

Destination IP: 192.190.175.254 (ftp) 



source Port: (11348) 
Destination Port: SMTP(25) 
Sequence Number: 104679726 (0x63d492e) 
Acknowledgement Number: 3878102249 (0xe72724e9) 
Data offset: 5 (0x5) 
Reserved: 0 
Urgent Field (URG): 0 
Acknowledgement field (ACK): 1 
Push Function (PSH): 1 
Reset connection (RST): 0 
Synchronize Sequence (SYN): 0 
NO More Data (fin): 0 
Window Size: 1834 (Ox72a) 
checksum: 43 E8 
urgent Pointer: 0 
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Data: 

0000 — 52 43 50 54 20 54 4F 3a 3c 6b rcpt TO:<k 
0010 — 61 68 6D 69 6E 2E 74 65 68 40 ahmin. teh@ 
0020 " 61 6d 64 2e 63 6F 60 3E Oo OA amd.com>. . 



***** Packet ID: 32 

ETHERNET==:::========^=^=:=::^===================^====^==^= 

Destination Address: 0000e8-061fl5 (smtplink) 
source Address: 0000a3''b0022a (T€CElite'N.b0022a) 
Ethernet Type: 08-00 (IP) 

Version: 4 

Header Length: 5 (0x5) 

Type of service: 00 

TOS Precedence: Routine (0) 

TOS Delay: Normal Del ay (0) 

TOS Throughput: Normal Throughput (0) 

TOS Reliability: Normal Reliability(O) 

Total Length: 40 (0x28) 

Identification: 37485 (0x926d) 

Reserved: 0 

Don't Fragment (DF): Don't Fragment (1) 

More Fragment (MF): Last Fragment (0) 

Fragment offset: 0 

Time to Live (TTL): 62 (0x3 e) 

Protocol: TCP (6) 

Header checksum: D9 3A 

source IP: 192.190.175.254 (ftp) 

Destination IP: 89.7.7.100 (smtplink) 

TCP==========================================:==== 

Source Port: SMTP(25) 

Destination Port: (11348) 

Sequence Number: 3878102249 (0xe72724e9) 

Acknowledgement Number: 104679756 (0x63d494c) 

Data offset: 5 (0x5) 

Reserved: 0 

urgent Field (URG): 0 

Acknowledgement field (ACK): 1 

Push Function (PSH): 0 

Reset connection (RST) : 0 

Synchronize Sequence (SYN): 0 

No More Data (FIN): 0 

window Size: 32736 (0x7 feO) 

Checksum: D6 C4 

Urgent Pointer: 0 



***** Packet id: 33 ***** 

ETHERNET=======:^=======:=====^===================~= 

Destination Address: 0000e8-061fl5 (smtplink) 
source Address: 0000a3-b0022a (TecElite-N.b0022a) 
Ethernet Type: 08-00 (IP) 

Version: 4 

Header Length: 5 (0x5) 

Type of service: 00 

TOS Precedence: Routine (0) 

TOS Delay: Normal Del ay (0) 

TOS Throughput: Normal Throughput (0) 

TOS Reliability: Normal Reliability(O) 

Total Length: 82 (0x52) 
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Identification: 37493 (0x9275) 
Reserved: 0 

Don't Fragment (DF): Don't Fragment (1) 

More Fragment (MF): Last Fragment (0) 

Fragment offset: 0 

Time to Live (TTL): 62 (0x3e) 

Protocol: TCP (6) 

Header checksum: D9 08 

source IP: 192.190.175.254 (ftp) 

Destination IP: 89.7.7.100 (smtpJink) 

source Port: SMTP(25) 

Destination Port: (11348) 

Sequence Number: 3878102249 (0xe72724e9) 

Acknowledgement Number: 104679756 (0x63d494c) 

Data Offset: 5 (0x5) 

Reserved: 0 

urgent Field (URG): 0 

Acknowledgement field (ACK): 1 

Push Function (PSH): 1 

Reset Connection (rst): 0 

Synchronize Sequence (SYN): 0 

No More Data (FIN): 0 

window Size: 32736 (0x7 feO) 

Checksum: AF 57 

Urgent Pointer: 0 

Data: 

0000 — 32 35 30 20 3C 6B 61 68 6D 69 250 <kahmi 

0010 — 6E 2E 74 65 68 40 61 6D 64 2E n. teh@amd. 

0020 63 6f 6d 3E 2e 2E 2E 20 52 65 com>. . . Re 

0030 — 63 69 70 69 65 6E 74 20 6f 6b cipient ok 

0040 — OD OA 



***** Packet id: 34 ***** 

ETHERNET==^==:=::=:=:^===:=^====:====================::===========^^ 

Destination Address: aa0004-000104 (dec. 000104) 
source Address: 0000e8-061fl5 (smtplink) 
Ethernet Type: 08-00 (IP) 

Version: 4 

Header Length: 5 (0x5) 

Type of Service: 00 

TOS Precedence: Routine (0) 

TOS Delay: Normal Del ay (0) 

TOS Throughput: Normal Throughput (0) 

TOS Reliability: Normal Reliability(O) 

Total Length: 47 (0x2 f) 

Identification: 3742 (0xe9e) 

Reserved: 0 

Don't Fragment (DF): May Fragment (0) 

More Fragment (MF): Last Fragment(O) 

Fragment Offset: 0 

Time to Live (TTL): 64 (0x40) 

Protocol: TCP (6) 

Header checksum: 98 03 

Source IP: 89.7.7.100 (smtplink) 

Destination IP: 192.190.175.254 (ftp) 

Source Port: 1^11348) 

Destination Port: SMTP (2 5) 

Sequence Number: 104679756 (0x63d494c) 
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Acknowledgement Number: 3878102291 (0xe7272513) 

Data Offset: 5 (0x5) 

Reserved: 0 

urqent Field (URG): 0 

Acknowledgement field (ACK): 1 

Push Function (PSH): 1 

Reset connection (RST): 0 

Synchronize Sequence (SYN): 0 

NO More Data (FIN): 0 

Window Size: 1792 (0x700) 

Checksum: 8C DC 

urgent Pointer: 0 

Data: 44 41 54 41 20 OD OA DATA 



***** Packet ID: 35 ***** 

ETHERNET===============================:^^=====:=^===:=^ 

Destination Address: 0000e8-061fl5 (smtplink) 
source Address: 0000a3-b0022a (TecElite'N.b0022a) 
Ethernet Type: 08-00 (IP) 

Version: 4 

Header Length: 5 (0x5) 

Type of service: 00 

TOS Precedence: Routine(O) 

TOS Delay: Normal Del ay (0) 

TOS Throuqhput: Normal Throughput (0) 

TOS Reliability: Normal Reliability(O) 

Total Length: 90 (Ox 5a) 

Identification: 37494 (0x9276) 

Reserved: 0 

Don't Fragment (DF): Don't Fragment (1) 

More Fragment (MF): Last Fragment (0) 

Fragment Offset: 0 

Time to Live (TTL): 62 (0x3e) 

Protocol: TCP (6) 

Header Checksum: d8 FF 

source IP: 192.190.175.254 (ftp) 

Destination IP: 89.7.7.100 (smtplink) 

source Port: smtp(25) 

Destination Port: (11348) 

sequence Number: 3878102291 (0xe7272513) 

Acknowledgement Number: 104679763 (0x63d4953) 

Data Offset: 5 (0x5) 

Reserved: 0 

urqent Field (URG): 0 

Acknowledgement field (ack): 1 

Push Function (PSH): 1 

Reset Connection (RST): 0 

Synchronize Sequence (SYN): 0 

N 
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• Exhibit B5: The contents of files mfaptpkt.txt and mfaptpkt2.txt that are files that 
contain the elements that were extracted by the parsing/extracting of 



i 



mfaptpkt. txt 

42 

08 00 20 13 10 D2 00 AO 24 75 C7 78 08 00 45 00 
00 30 BO 6C 40 00 80 06 94 14 59 06 06 03 59 07 
FE 36 09 53 00 6E lA 5D 8A 6E 50 DA 49 60 50 18 
ID 48 BF 97 00 00 52 45 54 52 20 32 OD OA FD 6E 
9D F5 

*- *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ it_ 
4B 

00 AO 24 75 C7 78 08 00 20 13 10 D2 08 00 45 00 
00 39 16 03 00 00 3C 06 B2 75 59 07 FE 36 59 06 
06 03 00 6E 09 53 50 DA 49 60 lA 5D 8A 76 50 18 
10 00 5d 6C 00 00 28 4f 48 20 31 33 35 31 20 6F 
63 74 65 74 73 OD OA CA EO 6A 81 
*_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ 

40 

08 00 20 13 10 D2 00 AO 24 75 C7 78 08 00 45 00 

00 28 81 6C 40 00 80 06 93 IC 59 06 06 03 59 07 

FE 36 09 53 00 6E lA 5D 8A 76 50 DA 49 71 50 10 

ID 3A 93 73 00 00 00 00 00 00 00 00 02 03 21 C2 
*_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ 

460 

00 AO 24 75 C7 78 08 00 20 13 10 D2 08 00 45 00 

05 5C 16 05 00 00 3C 06 AD 50 59 07 FE 36 59 06 

06 03 00 6E 09 53 50 DA 49 71 lA 5D 8A 76 50 18 
10 00 53 11 00 00 52 65 74 75 72 6E 2D 50 61 74 

68 3A 20 3C 6A 6D 65 74 7A 67 65 72 40 74 65 63 
65 6C 69 74 65 2E 63 6F 6D 3E OD OA 52 65 63 65 

69 76 65 64 3A 20 66 72 6F 6D 20 6E 61 74 61 64 
6D 2E 74 65 63 65 6C 69 74 65 2E 63 6F 6D 20 62 
79 20 73 75 70 65 72 2E 74 65 63 65 6C 69 74 65 
2E 63 6F 6D 20 28 34 2E 31 2F 53 4D 49 2D 34 2E 
31 29 OD OA 09 69 64 20 41 41 32 38 34 30 38 38 
20 54 68 75 2C 20 31 30 20 53 65 70 20 39 38 20 
31 37 3 A 33 37 3A 33 37 20 50 44 54 OD OA 52 65 
63 65 69 76 65 64 3A 20 66 72 6F 6D 20 73 6D 74 

70 6C 69 6E 68 2e 74 65 63 65 6C 69 74 65 2E 63 
6F 6D 20 28 73 6D 74 70 6C 69 6E 68 20 58 38 39 
2E 37 2E 37 2E 31 30 30 5D 29 OD OA 09 62 79 20 
6E 61 74 61 64 6d 2E 74 65 63 65 6C 69 74 65 2E 
63 6F 6D 20 28 38 2E 38 2E 37 2F 38 2E 38 2E 37 
29 20 77 69 74 68 20 53 4D 54 50 20 69 64 20 52 
41 41 31 37 32 34 35 3B OD OA 09 54 68 75 2C 20 
31 30 20 53 65 70 20 31 39 39 38 20 31 37 3A 33 
39 3A 30 34 20 2D 30 37 30 30 OD OA 52 65 63 65 
69 76 65 64 3A 20 66 72 6F 6D 20 63 63 3A 4D 61 
69 6C 20 62 79 20 73 6D 74 70 6C 69 6E 68 2E 74 
65 63 65 6C 69 74 65 2E 63 6F 6D OD OA 09 69 64 
20 41 41 39 30 35 34 37 34 38 32 39 20 54 68 75 
2C 20 31 30 20 53 65 70 20 39 38 20 31 37 3A 34 
37 3A 30 39 20 50 44 54 OD OA 44 61 74 65 3A 20 
54 68 75 2C 20 31 30 20 53 65 70 20 39 38 20 31 
37 3A 34 37 3A 30 39 20 50 44 54 OD OA 46 72 6F 
6D 3A 20 4A 6F 68 6E 20 4D 65 74 7a 67 65 72 20 
3C 6A 6D 65 74 7A 67 65 72 40 74 65 63 65 6C 69 
74 65 2E 63 6F 6D 3E OD OA 45 6E 63 6F 64 69 6E 
67 3A 20 33 32 34 20 54 65 78 74 OD OA 4D 65 73 

73 61 67 65 2D 49 64 3A 20 3C 39 38 30 38 31 30 

39 30 35 34 2E 41 41 39 30 35 34 37 34 38 32 39 

40 73 6d 74 70 6C 69 6E 68 2E 74 65 63 65 6C 69 

74 65 2E 63 6F 6D 3E OD OA 54 6F 3A 20 62 6C 65 
61 76 79 40 74 65 63 65 6C 69 74 65 2E 63 6F 6D 
2C 20 61 63 68 61 64 64 61 40 74 65 63 65 6C 69 
74 65 2E 63 6F 6D 2C 20 64 61 76 65 63 40 74 65 
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fill atJl.UtK L • L/^ L 

63 65 6C 69 74 65 2E 63 6F 6D 2C OD OA 20 20 20 
20 20 20 20 20 44 61 76 69 64 20 4C 75 6F 20 3C 

64 6C 75 6F 40 74 65 63 65 6C 69 74 65 2E 63 6F 
6D 3E 2C 20 6C 6F 77 64 65 72 40 74 65 63 65 6C 
69 74 65 2E 63 6F 6D 2C OD OA 20 20 20 20 20 20 
20 20 65 77 68 65 65 6C 65 72 40 74 65 63 65 6C 
69 74 65 2E 63 6F 6D 2C 20 66 6E 6F 6F 6E 40 74 

65 63 65 6C 69 74 65 2E 63 6F 6D 2C 20 66 72 65 

64 6D 40 74 65 63 65 6C 69 74 65 2E 63 6F 6D 2C 
OD OA 20 20 20 20 20 20 20 20 6A 6D 61 69 78 6E 

65 72 40 74 65 63 65 6C 69 74 65 2E 63 6F 6D 2C 
20 6A 6F 74 69 73 40 74 65 63 65 6C 69 74 65 2E 
63 6F 6D 2C OD OA 20 20 20 20 20 20 20 20 4B 69 
6d 20 44 61 76 69 73 20 3C 6B 64 61 76 69 73 40 
74 65 63 65 6C 69 74 65 2E 63 6F 6D 3E 2c 20 72 
61 6D 40 74 65 63 65 6C 69 74 65 2E 63 6F 6D 2C 
OD OA 20 20 20 20 20 20 20 20 52 6F 62 20 52 69 
74 7A 20 3C 72 72 69 74 7A 40 74 65 63 65 6C 69 

74 65 2E 63 6F 6D 3E 2C 20 72 73 64 69 65 74 7 A 
40 74 65 63 65 6C 69 74 65 2E 63 6F 6D 2C 20 73 
6B 69 70 40 74 65 63 65 6C 69 74 65 2E 63 6F 6D 
OD OA 53 75 62 6A 65 63 74 3A 20 4E 65 78 74 20 
47 65 6E 65 72 61 74 69 6F 6E 20 50 72 6F 64 75 
63 74 20 44 69 73 63 75 73 73 69 6F 6E OD OA OD 
OA OD OA 53 75 62 6A 65 63 74 3A 20 4E 65 78 74 
20 47 65 6E 65 72 61 74 69 6F 6E 20 50 72 6F 64 

75 63 74 20 44 69 73 63 75 73 73 69 6F 6E OD OA 

OD OA 49 20 77 6F 75 6C 64 20 6C 69 68 65 20 74 
*- *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ 

40 

08 00 20 13 10 D2 00 AO 24 75 C7 78 08 00 45 00 

00 28 B2 6C 40 00 80 06 92 IC 59 06 06 03 59 07 

FE 36 09 53 00 6E lA 5D 8A 76 50 DA 4E A5 50 10 

22 38 89 41 00 00 00 00 00 00 00 00 BA 3C 6B D6 
*_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ 
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mfaptpktZ. txt 

05 
42 

08 00 20 13 10 D2 00 AO 24 75 C7 78 08 00 45 00 
00 30 BO 6C 40 00 80 06 94 14 59 06 06 03 59 07 
FE 36 09 S3 00 6E lA 5D 8A 6E 50 DA 49 60 50 18 
ID 4B BF 97 00 00 52 45 54 52 20 32 OD OA FD 6E 
9D F5 
48 

00 AO 24 75 C7 78 08 00 20 13 10 D2 08 00 45 00 
00 39 16 03 00 00 3C 06 B2 75 59 07 FE 36 59 06 
06 03 00 6E 09 53 50 DA 49 60 lA 5D 8A 76 50 18 
10 00 5D 6C 00 00 28 4F 48 20 31 33 35 31 20 6F 
63 74 65 74 73 OD OA CA EO 6A Bl 
40 

08 00 20 13 10 D2 00 AO 24 75 C7 78 08 00 45 00 
00 28 Bl 6C 40 00 80 06 93 IC 59 06 06 03 59 07 
FE 36 09 53 00 6E lA 5D 8A 76 50 DA 49 71 50 10 
ID 3A 93 73 00 00 00 00 00 00 00 00 02 03 21 C2 
0460 

00 AO 24 75 C7 78 08 00 20 13 10 D2 08 00 45 00 

05 5C 16 05 00 00 3C 06 AD 50 59 07 FE 36 59 06 

06 03 00 6E 09 53 50 DA 49 71 lA 5D 8A 76 50 18 
10 00 53 11 00 00 52 65 74 75 72 6E 2D 50 61 74 

68 3A 20 3C 6A 6D 65 74 7A 67 65 72 40 74 65 63 
65 6C 69 74 65 2E 63 6F 6D 3E OD OA 52 65 63 65 

69 76 65 64 3 A 20 66 72 6F 6D 20 6E 61 74 61 64 
6D 2E 74 65 63 65 6C 69 74 65 2E 63 6F 6d 20 62 
79 20 73 75 70 65 72 2E 74 65 63 65 6C 69 74 65 
2E 63 6F 6D 20 28 34 2E 31 2F 53 4D 49 2D 34 2E 
31 29 OD OA 09 69 64 20 41 41 32 38 34 30 38 3B 
20 54 68 75 2C 20 31 30 20 53 65 70 20 39 38 20 
31 37 3A 33 37 3A 33 37 20 50 44 54 OD OA 52 65 
63 65 69 76 65 64 3A 20 66 72 6F 6D 20 73 6D 74 

70 6C 69 6E 6B 2E 74 65 63 65 6C 69 74 65 2E 63 
6F 6D 20 28 73 6D 74 70 6C 69 6E 68 20 58 38 39 
2E 37 2E 37 2E 31 30 30 5D 29 OD OA 09 62 79 20 
6E 61 74 61 64 6D 2e 74 65 63 65 6C 69 74 65 2E 
63 6F 6D 20 28 38 2E 38 2E 37 2F 38 2E 38 2E 37 
29 20 77 69 74 68 20 53 4D 54 50 20 69 64 20 52 
41 41 31 37 32 34 35 38 OD OA 09 54 68 75 2C 20 
31 30 20 53 65 70 20 31 39 39 38 20 31 37 3A 33 
39 3 A 30 34 20 2D 30 37 30 30 OD OA 52 65 63 65 
69 76 65 64 3 A 20 66 72 6F 6D 20 63 63 3 A 4D 61 
69 6C 20 62 79 20 73 6D 74 70 6C 69 6E 68 2E 74 
65 63 65 6C 69 74 65 2E 63 6F 6D OD OA 09 69 64 
20 41 41 39 30 35 34 37 34 38 32 39 20 54 68 75 
2C 20 31 30 20 53 65 70 20 39 38 20 31 37 3A 34 
37 3A 30 39 20 50 44 54 OD OA 44 61 74 65 3A 20 
54 68 75 2C 20 31 30 20 53 65 70 20 39 38 20 31 
37 3A 34 37 3A 30 39 20 50 44 54 OD OA 46 72 6F 
6D 3 A 20 4A 6F 68 6E 20 4D 65 74 7 A 67 65 72 20 
3C 6A 6D 65 74 7A 67 65 72 40 74 65 63 65 6C 69 
74 65 2E 63 6F 6D 3e OD OA 45 6e 63 6F 64 69 6E 
67 3A 20 33 32 34 20 54 65 78 74 OD OA 4D 65 73 

73 61 67 65 2D 49 64 3A 20 3C 39 38 30 38 31 30 

39 30 35 34 2E 41 41 39 30 35 34 37 34 38 32 39 

40 73 6D 74 70 6C 69 6e 68 2E 74 65 63 65 6C 69 

74 65 2E 63 6F 6D 3E OD OA 54 6F 3A 20 62 6C 65 
61 76 79 40 74 65 63 65 6C 69 74 65 2E 63 6F 6D 
2C 20 61 63 68 61 64 64 61 40 74 65 63 65 6C 69 
74 65 2E 63 6F 6D 2C 20 64 61 76 65 63 40 74 65 
63 65 6C 69 74 65 2E 63 6F 6D 2c OD OA 20 20 20 
20 20 20 20 20 44 61 76 69 64 20 4C 75 6F 20 3C 
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Exhibit B6: The contents of files mfaptkey.txt and mfaptkey2.txt that are files that 
contain the keys that were generated from the extracted data (Exhibit B4) and used 
for looking up the flow-entry database per element (c) of method claims 1 1 and 54, 
which are operations carried out by the lookup engine of element (e) of claim 29. 



mfaptkey. txt 

00 00 00 00 08 00 20 13 10 D2 00 AO 24 75 C7 78 

00 08 59 07 FE 36 00 00 00 00 00 00 00 00 00 00 

00 00 59 06 06 03 00 00 00 00 00 00 00 00 00 00 

00 00 00 2b 00 00 00 00 00 00 00 00 00 00 00 00 

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

00 00 00 00 00 00 00 47 00 6E 00 00 09 53 00 00 
*_ *_ *_ *_ *_ *_ *- *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ 

00 00 00 00 00 AO 24 75 C7 78 08 00 20 13 10 d2 

00 08 59 06 06 03 00 00 00 00 00 00 00 00 00 00 

00 00 59 07 FE 36 00 00 00 00 00 00 00 00 00 00 

00 00 00 2b 00 00 00 00 00 00 00 00 00 00 00 00 

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

00 00 00 00 00 00 00 47 09 53 00 00 00 6E 00 00 
*_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ 

00 00 00 00 08 00 20 13 10 D2 00 AO 24 75 C7 78 

00 08 59 07 FE 36 00 00 00 00 00 00 00 00 00 00 

00 00 59 06 06 03 00 00 00 00 00 00 00 00 00 00 

00 00 00 28 00 00 00 00 00 00 00 00 00 00 00 00 

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

00 00 00 00 00 00 00 47 00 6E 00 00 09 53 00 00 
*_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ 

00 00 00 00 00 AO 24 75 C7 78 08 00 20 13 10 D2 
00 08 59 06 06 03 00 00 00 00 00 00 00 00 00 00 
00 00 59 07 FE 36 00 00 00 00 00 00 00 00 00 00 
00 00 00 23 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 47 09 53 00 00 00 6E 00 00 

*- *_ *_ *_ *_ *_ *_ *_ *_ >)•_ *_ *_ *_ *_ *_ *_ it_ *_ 

00 00 00 00 08 00 20 13 10 D2 00 AO 24 75 C7 78 

00 08 59 07 FE 36 00 00 00 00 00 00 00 00 00 00 

00 00 59 06 06 03 00 00 00 00 00 00 00 00 00 00 

00 00 00 2B 00 00 00 00 00 00 00 00 00 00 00 00 

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

00 00 00 00 00 00 00 47 00 6E 00 00 09 53 00 00 
*- *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ *_ 
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mfaptkeyZ. txt 
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Exhibit B7: The contents of file MFATESTTXT that includes the decoded packets 
that were generated by operation of the method that includes the elements of each 
of method claims 1 1 and 54, by an apparatus that includes the elements of claim 29. 



HP ProbeViow/SNMP File Contains 148 Packets 



TO: 0800201310D2 
FROM: 00A02475C778 



^2:53:SO<0.000> 



Pkt: 1, Len: 66/66 

Ethernet: (00a02475c778 -> Sun 1310d2) 
Internet: 89.6.6.3 -> 89.7.254.54 

tos: 0 len: 48 Id: 0xb06c frago££: 0 

prot: TCP(6) xsuxq: 0x9414 
TCP: 2387 -> POP-3(110) seq: Ia5d8a6e 

ack: 50da4960 win: 7499 hi: 5 xs\m: 0xbf97 urg 

flags : <ACK><PUSH> 
data (8/8): 



type: IP (0x800) 
hi: 5 ver: 4 
flags: 0x2 ttl: 128 



*_*_*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 

2 TO: 00A02475C778 VHH^^2 : 53 : 50<0 . 002> 

FROM: 08002013 10D2 

Pkt: 2, Len: 75/75 

Ethernet: ( Sun 1310d2 -> 00a02475c778) type: IP(0x800) 
Internet: 89.7.254.54 -> 89.6.6.3 hi: 5 ver: 4 

tos: 0 len: 57 id: 0x1603 fragoff: 0 flags: 00 ttl: 60 

prot: TCP (6) xsum: 0xb275 
TCP: POP-3(110) -> 2387 seq: 50da4960 

ack: Ia5d8a76 win: 4096 hi: 5 xsvtm: 0x5d6c urg: 0 

flags: <ACK><PUSH> 
data (17/17): 



*-*-*-*-*-*-*-*-*-*-*-*-*-*-.*-*-*-*-*-*-*-*-*-*-* 

3 TO: 0800201310D2 ^^^^^2 : 53 : 5K0 .185> 

FROM: OOA02475C778 ^^^^^ 

Pkt: 3, Len: 64/64 

Ethernet: (00a02475c778 -> Sun 1310d2) type: IP(0x800) 

Internet: 89.6.6.3 -> 89.7.254.54 hi: 5 ver: 4 

tos: 0 len: 40 id: 0xkl6c fragoff: 0 flags: 0x2 ttl: 128 

prot: TCP (6) xsujn: 0x9 31c 

TCP: 2387 -> POP-3(110) seq: Ia5d8a76 

ack: 50da4971 win: 7482 hi: 5 xsum: 0x9373 urg: 0 

flags: <ACK> 



TO: 00A02475C778 
FROM: 0800201310D2 



22:53:51<0.002> 



type: IP (0x800) 
hi: 5 ver: 4 
flags: 00 ttl: 



Pkt: 4, Len: 1120/1390 

Ethernet: ( Sun 1310d2 -> 00a02475c778) 
Internet: 89.7.254.54 -> 89.6.6.3 

tos: 0 len: 1372 id: 0x1605 fragoff: 0 

prot: TCP(6) xsum: 0xad50 
TCP: POP-3(110) -> 2387 seq: 50da4971 

ack: Ia5d8a76 win: 4096 hi: 5 xsum: 0x5311 urg: 

flags : <ACK><PUSH> 



60 



data (60/1332): 



5 TO: 0800201310D2 ^HB22 : 53 : 51<0 . 198> 

PROM: 00A02475C778 

Pkt: 5, Len: 64/64 

Ethernet: ( 00a02475c778 -> Sun 1310d2) type: IP(0x800) 
Internet: 89.6.6.3 -> 89.7.254.54 hi: 5 ver: 4 

tos: 0 len: 40 Id: Oxb26c £rago££: 0 flags: 0x2 ttl: 128 

prot: TCP (6) xsum: 0x92 Ic 
TCP: 2387 -> POP-3(110) seq: Ia5d8a76 

ack: 50da4ea5 win: 8760 hi: 5 xsum: 0x8941 urg: 0 

flags: <ACK> 



*-*-*_*-*_*_*-*-*-*-*-*-*-♦-*-♦-*-*-*-*-*-*-*-*-'* 

6 TO: 0800201310D2 VPHR : 53 : 53<2 . 556> 

PROM: OOA02475C778 

Pkt: 6, Len: 66/66 

Ethernet: (00a02475c778 -> Sun 1310d2) type: IP(0x800) 
Internet: 89.6.6.3 89.7.254.54 hi: 5 ver: 4 

tos: 0 len: 48 id: 0xb36c fragoff: 0 flags: 0x2 ttl: 128 

prot: TCP (6) xs\im: 0x9114 
TCP: 2387 -> POP-3(110} seq: Ia5d8a76 

ack: 50da4ea5 win: 8760 hi: 5 xsum: Oxcb6a urg: 0 

flags: <ACK><PUSH> 
data (8/8): 



7 TO: 00A02475C778 ^■||^^2 : 53 : 53<0 . 001> 

FROM: 0800201310D2 ^^^^^ 

Pkt: 7, Len: 91/91 

Ethernet: ( Sun 1310d2 -> 00a02475c778) type: IP<0x800) 
Internet: 89.7.254.54 -> 89.6.6.3 hi: 5 ver: 4 

tos: 0 len: 73 id: 0x1609 fragoff: 0 flags: 00 ttl: 60 

prot: TCP(6) xsum: 0xb25f 
TCP: POP-*3(110) -> 2387 seq: 50da4ea5 

ack: Ia5d8a7e win: 4096 hi: 5 xsum: 0x3£4c urg: 0 

flags: <ACK><PUSH> 
data (33/33): 



8 TO: 0800201310D2 !fl|^|||||^2 : 53 : 53<0 . 002> 

FROM: 00A02475C778 

Pkt: 8, Len: 64/64 

Ethernet: (00a02475c778 -> Sun 1310d2) type: IP(Ox800) 

Internet: 89.6.6.3 -> 89.7.254.54 hit 5 ver: 4 

tos: 0 len: 46 id: 0xb46c fragoff: 0 flags: 0x2 ttl: 128 

prot: TCP(6) xsxun: 0x9016 

TCP: 2387 -> POP-3(110) seq: Ia5d8a7e 

ack: 50da4ec6 win: 8727 hi: 5 xsum: 0xel77 urg: 0 



flags : <ACK><PUSH> 
data (6/6): 



9 TO: 00A02475C778 ^■PKS : 53 :53<0 .029> 

FROH: 0800201310D2 

Pkt: 9, Len: 96/96 

Ethernet: { Sun 1310d2 -> 00a02475c778 ) type: IP(0x800) 
Internet: 89.7.254.54 -> 89.6.6.3 hi: 5 ver: 4 

tos: 0 len: 78 id; 0xl60a £rago££; 0 flags: 00 ttl: 60 

prot: TCP(6) xsuxn: 0xb259 
TCP: POP-3(1XO) -> 2387 seq: 50da4ec6 

ack: Ia5d8a84 win: 4096 hi: 5 xsum: Oxa04c urg: 0 

flags: <ACK><PUSH> 
data (38/38): 



*_*-*-*-*-*—♦-♦-*-*—*—*-*_*_*_*_*«*•*_*.*_*_*_*_* 

10 TO: 00A02475C778 ^^Bi^2 : 53 : 53<0 . 003> 

FROM: 0800201310D2 

Pkt: 10, Len: 64/64 

Ethernet: ( Sun 1310d2 -> 00a02475c778) type; IP(0x800) 
Internet: 89.7.254.54 -> 89.6.6.3 hi: 5 ver: 4 

tos: 0 len: 40 id: 0xl60b fragoff: 0 flags: 00 ttl: 60 

prot: TCP (6) xs\ixn: Oxb27e 
TCP: POP-3<X10) -> 2387 seq: 50da4eec 

ack: Ia5d8a84 win: 4096 hi: 5 xsum: 0x9b23 urg: 0 

flags: <ACK><FIN> 



11 TO: 0800201310D2 ^[|H^22 : 53 1 53<0 • 000> 

FROM: 00A02475C778 V 

Pkt: 11, Len: 64/64 

Ethernet: ( 00a02475c778 -> Sun 1310d2) type: IP{0x800) 

Internet: 89.6.6.3 -> 89.7.254.54 hi: 5 ver: 4 

tos: 0 len: 40 id: 0xb56c fragoff: 0 flags: 0x2 ttl: 128 

prot: TCP(6) xsum: 0x8 flc 

TCP: 2387 -> POP-3(110) seq: Ia5d8a84 

ack: 50da4eed win: 8689 hi: 5 xsum: 0x8932 urg: 0 

flags: <ACK> 



12 TO: 0800201310D2 

FROM: 00A02475C778 



i:53:53<0.031> 



Pkt: 12, Len: 64/64 

Ethernet: ( 00a02475c778 -> Sun 1310d2) 
internet: 89.6.6.3 -> 89.7.254.54 

tos: 0 len: 40 id: 0xb66c fragoff: 0 

prot: TCP (6) xsum: 0x8elc 
TCP: 2387 -> POP-3(110) seq: Ia5d8a84 



type: IP(0x800) 
hi: 5 ver: 4 
flags: 0x2 ttl: 



128 



ack: 50da4eed win: 8689 hi: 5 xsum: 0x8931 urg: 0 
flags: <ACK><F1N> 



13 TO: 00A02475C778 ■jj^B 22 : 53 : 53<0 . 001> 

FROM: 0800201310D2 ^^^^^ 

Pkt: 13, Len: 64/64 

Ethernet: ( Sun 1310d2 -> 00a02475c778) type: IP (0x800) 

Internet: 89.7.254.54 *> 89.6.6.3 hi: 5 ver: 4 

tos: 0 len: 40 Id: 0xl60c fragoff: 0 flags: 00 ttl: 60 

prot: TCP (6) xsum: 0xb27d 

TCP: POP-3(110) 2387 seq: 50da4eed 

ack: Ia5d8a85 win: 4096 hi: 5 xsum: 0x9b22 urg: 0 

flags: <ACK> 



14 TO: 006008COD710 

FROM: 00A076A010F2 




2:53:58<4.755> 



Pkt: 14, Len: 64/64 

Ethernet: (00a076a010f 2 -> 006008c0d710) type: ZP(0x800) 
Internet: 89.89.24.6 89.75.23.24 hi: 5 ver: 4 

tos: 0 len: 44 id: OxSffe fragoff: 0 flags: 0x2 ttl: 128 

prot: TCP (6) xsiim: 0xb90b 
TCP: 1460 -> netb-ses(139) seq: 01be3a7e 

ack: win: 8192 hi: 6 xsum: 0x53e9 urg: 0 

flags: <SYN> mss: 1460 



15 TO: 00A076A010F2 

FROM: 006008C0D710 



22:53:58<0.001> 



Pkt: 15, Len: 64/64 

Ethernet: (006008c0d710 -> 00a076a010f 2) type: IP(0x800) 
Internet: 89.75.23.24 -> 89.89.24.6 hi: 5 ver: 4 

tos: 0 len: 44 id: 0x497c fragoff: 0 flags: 0x2 ttl: 128 

prot: TCP (6) xsum: 0xcf8d 
TCP: netb-ses(139) -> 1460 seq: lecd513b 

ack: 01be3a7f win: 8760 hi: 6 xsum: 0xel97 urg: 0 

flags: <ACK><SYN> mss: 1460 



16 TO: 006008C0D710 

FROM: 00A076A010F2 



I 22:53:58<0.000> 



Pkts 16, Len: 64/64 

Ethernet: (00a076a010f 2 -> 006008c0d710) type: IP(0x800) 
Internet: 89.89.24.6 -> 89.75.23.24 hi: 5 ver: 4 

tos: 0 len: 40 id: 0x60fe fragoff: 0 flags: 0x2 ttl: 128 

prot: TCP (6) xsum: 0xb80f 



Exhibit B8: Protocol Definition Language (PDL) Reference Guide (the document 
MFS-PDL-Reference.pdf) that provides a reference to the protocol definition 
language used in cpl files. 
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1. Introduction 

The MeterFlow Protocol Definition Language (PDL) is a special purpose language 
used to describe network protocols and all the fields within the protocol headers. 

Within this document, protocol descriptions (PDL files) are referred to as PDL or 
rules when there in no risk of confusion with other types of descriptions. 

PDL uses both form and organization similar to the data structure definition part of the 
C programming language and the PERL scripting language. Since PDL was derived 
from a language used to decode network packet contact, the authors have mixed the 
language format with the requirements of packet decoding. This results in an 
expressive language that is very familiar and comfortable for describing packet content 
and the details required representing a flow. 

1.1 Summary 

MeterFlow PDL is a non-procedural Forth Generation language (4GL). This means is 
describes what needs to be done without describing how to do it. The details of how 
are hidden in the compiler and the Compiled Protocol Layout (CPL) optimization 
utiUty. 

In addition, it is used to describe network flows by defining which fields are the 
address fields, which are the protocol type fields, etc. 

Once a PDL file is written, it is compiled using the Netscope compiler (nsc), which 
produces the MeterFlow database (MeterFlow.db) and the Netscope database 
(Netscope.db). The MeterFlow database contains the flow definitions and the 
Netscope database contains the protocol header definitions. 

These databases are used by programs like: mfkeys, which produces flow keys; mfcpl, 
which produces flow definitions in CPL format; mfpkts which produces sample 
packets of all known protocols; and netscope, which decodes Sniffer™ and tcpdump 
files. 

Due to its size, electronic media copies of the documentation are not provided but can 
be made available if necessary. 

1.2 Document Conventions 

The following conventions will be used throughout this document: 

Small courier typeface indicates C code examples or function names. Functions are 
written with parentheses after them [function ( ) ], variables are written just as their 
names [variables], and structure names are written prefixed with "struct" 
[struct packet]. 
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Italics indicate a filename (for instance, mworks/base/h/baseM). Filenames will usually 
be written relative to the root directory of the distribution. 

Constants are expressed in decimal, unless written "Ox . . . the C language notation 
for hexadecimal numbers. 



1 

i 
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2. Language Structure 

TBD 

3. Program Structure 

A MeterFlow PDL decodes and flow set is a non-empty sequence of statements. 

There are four basic types of statements or definitions available in MeterFlow PDL: 

FIELD, 
GROUP, 
, PROTOCOL and 
FLOW. 



3.1 FIELD Definitions 

The FIELD definition is used to define a specific string of bits or bytes in the packet. 
The FIELD definition has the following format: 

Name FIELD 

SYNTAX Type [ { Envuns } ] 

DISPLAY-HINT "FormatString" 

LENGTH "Expression" 

FLAGS FieldFlags 

ENCAP FieldName [ , FieldNaine2 ] 

LOOKUP LookupType [ Filename ] 

ENCODING EncodingType 

DEFAULT "value" 

DESCRIPTION "Description" 

Where only the FIELD and SYNTAX lines are required. All the other lines are 
attribute lines, which define special characteristics about the FIELD. Attribute lines 
are optional and may appear in any order. Each of the attribute lines are described in 
detail below: 

3.1 .1 SYNTAX Type [ { Enums } ] 

This attribute defines the type and, if the type is an INT, BYTESTRING, 
BITSTRING, or SNMPSEQUENCE type, the enumerated values for the FIELD. The 
currently defined types are: 



INTinumBits) 


Integer that is numBits bits long. 


UNSIGNED iminumBits) 


Unsigned integer that is numBits bits long. 



jl 
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BYTESTKlNG(numBytes) 


String that is numBytes bytes long. 


BYTESTRING(7?7../?2) 


String that ranges in size from Rl to R2 bytes. 


BlTSTRING(mmBits) 


String that is numBits bits long. 


LSTRIMGilenBytes) 


String with lenBytes header. 


NSTRING 


Null terminated string. 


DNSSTRING 


DNS encoded string. 


SNMPOID 


SNMP Object Identifier. 


SNMPSEQUENCE 


SNMP Sequence. 


SNMPTIMETICKS 


SNMP TimeTicks. 


COMBO fieldl field2 


Combination pseudo field. 


3.1.2 DISPLAY-HINT "FormatString" 

This attribute is for specifying how the value of the FIELD is displayed. The currently 

supported formats are: 


Numx 


Print as a num byte hexidecimal number. 


Numd 


Print as a num byte decimal number. 


Numo 


Print as a num byte octal number. 


Numb 


Print as a num byte binary number. 


Numa 


Print num bytes in ASCII format. 


Text 


Print as ASCII text. 


HexDump 


Print in hexdump format. 



3.1.3 LENGTH "Expression" 

This attribute defines an expression for determining the FIELD'S length. Expressions 
are arithmetic and can refer to the value of other FIELD'S in the packet by adding a $ 
to the referenced field's name. For example, 'X$tcpHeaderLen *4) - 20" is a valid 
expression if tcpHeaderLen is another field defined for the current packet. 



3.1.4 FLAGS FieldFlags 

The attribute defines some special flags for a FIELD. The currently supported 
FieldFlags are: 



SAMELAYER 


Display field on the same layer as the previous field. 


NOLABEL 


Don't display the field name with the value. 
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NOSHOW 


Decode the field but don't display it. 


SWAPPED 


The integer value is swapped. 



3.1.5 ENCAP FieldName [ , FieldName2 ] 

This attribute defines how one packet is encapsulated inside another. Which packet is 
determined by the value of the FieldName field. If no packet is found using FieldName 
then FieldName2 is tried. 



3.1.6 LOOKUP LookupType [ Filename ] 

This attribute defines how to lookup the name for a particular FIELD value. The 
currently supported LookupTypes are: 



SERVICE 


Use getservbyportQ. 


HOSTNAME 


Use gethostbyaddr(). 


MACADDRESS 


Use $METERFLOW/con£'mac2ip.cf. 


FILE file 


Use file to lookup value. 



3.1.7 ENCODING EncodingType 

This attribute defines how a FIELD is encoded. Currently, the only supported 
EncodingType is BER (for Basic Encoding Rules defined by ASN.l). 



3.1.8 DEFAULT "value" 

This attribute defines the default value to be used for this field when generating sample 
packets of this protocol. 

3.1.9 DESCRIPTION "Description" 

This attribute defines the description of the FIELD. It is used for informational 
purposes only. 
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3.2 GROUP Definitions 

The GROUP definition is used to tie several related FIELDs together. The GROUP 
definition has the following format: 

Name GROUP 

LENGTH "Expression" 
OPTIONAL "Condition" 

SUMMARIZE "Condition" : " Formats tring" [ 
"Condition" : "Formats tring" . . . ] 
DESCRIPTION "Description" 
: := { Name=Field0r6roup [ , 
Name=FieldOrGroup . . . ] } 

Where only the GROUP and ::= lines are required. All the other lines are attribute 
lines, which define special characteristics for the GROUP. Attribute lines are optional 
and may appear in any order. Each attribute line is described in detail below: 

3.2.1 LENGTH "Expression" 

This attribute defines an expression for determining the GROUP*s length. Expressions 
are arithmetic and can refer to the value of other FIELD'S in the packet by adding a $ 
to the referenced field's name. For example, "(^^cpHeaderLen *4) - 20" is a valid 
expression if tcpHeaderLen is another field defined for the current packet. 

3.2.2 OPTIONAL "Condition" 

This attribute defines a condition for determining whether a GROUP is present or not. 
Valid conditions are defined in the Conditions section below. 

3.2.3 SUMIVIARIZE "Condition" : "FormatString" [ "Condition" : 
"FormatString"... ] 

This attribute defines how a GROUP will be displayed in Detail mode. A different 
format (FormatString) can be specified for each condition (Condition). Valid 

conditions are defined in the Conditions section below. Any FIELD'S value can be 
referenced within the FormatString by proceeding the FIELD'S name with a $. In 
addition to FIELD names there are several other special $ keywords: 



SLAYER 


Displays the current protocol layer. 


$GROUP 


Displays the entire GROUP as a table. 


SLABEL 


Displays the GROUP label. 


%field 


Displays the field value (use enumerated name if available). 


%:field 


Displays the field value (in raw format). 
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3.2.4 DESCRIPTION "Description" 

This attribute defines the description of the GROUP. It is used for informational 
purposes only. 

3.2.5 ::= { Name=FieldOrGroup [ , Name=FieldOrGroup... ] } 

This defines the order of the fields and subgroups within the GROUP. 
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3.3 PROTOCOL Definitions 

The PROTOCOL definition is used to define the order of the FIELDs and GROUPs 
within the protocol header. The PROTOCOL definition has the following format: 

Name PROTOCOL 

SUMMARIZE "Condition" : " Formats tring" [ 
"Condition" : "Formats tring" ... ] 
DESCRIPTION "Description" 
REFERENCE "Reference" 
: := { Name=FieldOrGroup [ , 
NamesFieldOrGroup . . . ] } 

Where only the PROTOCOL and ::= lines are required. All the other lines are attribute 
lines, which define special characteristics for the PROTOCOL. Attribute lines are 
optional and may appear in any order. Each attribute line is described in detail below: 

3.3.1 SUMMARIZE "Condition" : "FormatStrIng" [ "Condition" : 
"FormatStrIng"... ] 

This attribute defines how a PROTOCOL will be displayed in Summary mode. A 
different format (FormatString) can be specified for each condition (Condition). Valid 
conditions are defined in the Conditions section below. Any FIELD'S value can be 
referenced within the FormatString by proceeding the FIELD'S name with a $. In 
addition to FIELD names there are several other special $ keywords: 



SLAYER 


Displays the current protocol layer. 


SVARBIND 


Displays the entire SNMP VarBind list. 


%fielcl 


Displays the field value (use enumerated name if available). 


%:field 


Displays the field value (in raw format). 


%§field 


Counts all occurrences of field. 


%*field 


Lists all occurrences of field. 



3.3.2 DESCRIPTION "Description 



This attribute defines the description of the PROTOCOL. It is used for informational 
purposes only. 

3.3.3 REFERENCE "Reference" 

This attribute defines the reference material used to determine the protocol format. It 
is used for informational purposes only. 

I 

3.3.4 ::= { NamesFieldOrGroup [ , Name=FieldOrGroup... ] > 

This defines the order of the FIELDs and GROUPs within the PROTOCOL. 
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3.4 FLOW Definitions 

The FLOW definition is used to define a network flow by describing where the 
address, protocol type, and port numbers are in a packet. The FLOW definition has the 
following format: 

Name FLOW 

HEADER { Option [, Option...] } 
DLC-LAYER { Option [, Option...] } 
NET-LAYER { Option [, Option...] } 
CONNECTION { Option [, Option...] } 
PAYLOAD { Option [, Option...] } 
CHILDREN { Option [, Option...] } 
STATE -BASED 
STATES "Definitions" 

Where only the FLOW line is required. All the other lines are attribute lines, which 
define special characteristics for the FLOW. Attribute lines are optional and may 
appear in any order. However, at least one attribute line must be present. Each 
attribute line is described in detail below: 



3.4.1 HEADER {Option [.Option...]} 

This attribute is used to describe the length of the protocol header. The currently 
supported Options are: 



LENGTH=«Mm6er 


Header is a fixed length of size number. 


LENGTH=y/eW 


Header is variable length determined by value of field 


IN-WORDS 


The units of the header length are in 32-bit words rather than bytes. 



3.4.2 DLC-LAYER { Option [, Option...] } 

If the protocol is a data link layer protocol, this attribute describes it. The currently 
supported Options are: 



DESTINATION=y?eW 


Indicates which field is the DLC destination address. 


SOURCE=y/eW 


Indicates which field is the DLC source address. 


PROTOCOL 


Indicates this is a data link layer protocol. 


TUNNELING 


Indicates this is a tunneling protocol. 


3.4.3 NET-LAYER { Option [, Option...] > 

If the protocol is a network layer protocol, then this attribute describes it. The 
currently supported Options are: 


DESTINATION=y/eW 


Indicates which field is the network destination address. 
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SOVRCE=field 


Indicates which field is the network source address. 


TUNNELING 


Indicates this is a tunneling protocol. 


FRAGMENTATION=0;pe 


Indicates this protocol supports fragmentation. There are 
currently two fragmentation types: IPV4 and IPV6, 



3.4.4 CONNECTION { Option [, Option...] } 



If the protocol is a connection-oriented protocol, then this attribute describes how 
connections are established and torn down. The currently supported Options are: 



IDENTIFIER=y/e/^ 


Indicates the connection identifier field. 


C0NNECT-START='y7ag" 


Indicates when a connection is being initiated. 


C0NNECT-C0MPLETE='y7ag" 


Indicates when a connection has been established. 


DISC0NNECT-START='y7ag" 


Indicates when a connection is being torn down. 


DISC0NNECT-C0MPLETE='y7ag" 


Indicates when a connection has been torn down. 


INHERITED 


Indicates this is a connection-oriented protocol 

but the parent protocol is where the connection is 

established. 

• 



3.4.5 PAYLOAD { Option [, Option...] } 

This attribute describes how much of the payload from a packet of this type should be 
stored for later use during analysis. The currently supported Options are: 



INCLUDE-HEADER 


Indicates that the protocol header should be included. 


LEHG'YH=number 


Indicates how many bytes of the payload should be stored. 


DATA=/ield 


Indicates which field contains the payload. 


3.4.6 CHILDREN { Option [, Option...] } 

This attribute describes how children protocols are determined. The currently 
supported Options are: 


DESTINATION=//eW 


Indicates which field is the destination port. 


SOURCE=//eW 


Indicates which field is the source port. 


LLCCHECK=y7ow 


Indicates that if the DESTINATION field is less than OxOSDC 
then use flow instead of the current flow definition. 


3.4.7 STATE-BASED 



This attribute indicates that the flow is a state-based flow. 
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3.4.8 STATES "Definitions" 

This attribute describes how children flows of this protocol are determined using 
states. See the State Definitions section below for how these states are defined. 
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3.5 CONDITIONS 



Conditions are used with the OPTIONAL and SUMMARIZE attributes and may 
consist of the following: 



Value 1 == Value2 


Valuel equals Value2. Works with string values. 


Valuel != Value2 


Valuel does not equal Value2. Works with string values. 


Valuel <= Value2 


Valuel is less than or equal to Value2. 


Valuel >= Value2 


Valuel is greater than or equal to Value2. 


Valuel < Value2 


Valuel is less than Value2. 


Valuel > Value2 


Valuel is greater than Value2. 


Field m/regex/ 


Field matches the regular expression regex. 



Where Valuel and Value2 can be either FIELD references (field names preceded by a 
$) or constant values. Note that compound conditional statements (using AND and 
OR) are not currently supported. 
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3.6 STATE DEFINITIONS 

Many applications running over data networks utilize complex methods of classifying 
traffic through the use of multiple states. State definitions are used for managing and 
maintaining leamed states from traffic derived from the network. 

The basic format of a state definition is: 

StateName: Operand Parameters [ Operand Parameters,..] 

The various states of a particular flow are described using the following operands: 

3-6.1 CHECKCONNECT, operand 

Checks for connection. Once connected executes operand 

3.6.2 GOTO state 

Goes to state, using the current packet. 

3.6.3 NEXTsfafe 

Goes to state, using the next packet. 

3.6.4 DEFAULT operand 

Executes operand when all other operands fail. 

3.6.5 CHILD protocol 

Jump to child protocol and perform state-based processing (if any) in the child. 

3.6.6 WAIT numPackets, operandi, operandi 

Waits the specified number of packets. Executes operandi when the specified number 
of packets have been received. Executes operand2 when a packet is received but it is 
less than the number of specified packets. 

3.6.7 MATCH 'string' weight offset LF-offset range LF-range, operand 

Searches for a string in the packet, executes operand if found. 

3.6.8 CONSTANT number offset range, operand 

Checks for a constant in a packet, executes operand if found. 

3.6.9 EXTRACTIP offset destination, operand 

Extracts an IP address from the packet and then executes operand, 

3.6.10 EXTRACTPORT offset destination, operand 

Extracts a port number from the packet and then executes operand. 
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3.6.11 CREATEREDIRECTEDFLOW, operand 

Creates a redirected flow and then executes operand. 
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4. Example PDL Rules 

The following section contains several examples of PDL Rule files. 

4.1 Ethernet 

The following is an example of the PDL for Ethernet: 

MacAddress FIELD 

SYNTAX BYTESTRING (6) 

DISPLAY-HINT "Ix: " 
LOOKUP MACADDRESS 
DESCRIPTION 

''MAC layer physical address" 

FIELD 

SYNTAX INT (16) 

DISPLAY-HINT "Ix: " 
LOOKUP FILE ''EtherType.cf" 

DESCRIPTION 

"Ethernet type field" 

FIELD 

SYNTAX BYTESTRING (4 6 . . 1500) 

ENCAP etherType 
DISPLAY-HINT "HexDump" 
DESCRIPTION 

"Ethernet data" 

PROTOCOL 
DESCRIPTION 

"Protocol format for an Ethernet frame" 
REFERENCE "RFC 894" 
::= { MacDest=macAddress, MacSrc=macAddress, 
EtherType=etherType, 
Data=etherData } 

ethernet FLOW 

HEADER { LENGTH=14 } 
DLC-LAYER { 

SOURCE=MacSrc, 

DESTINATION=MacDest, 

TUNNELING, 

PROTOCOL 

} 

CHILDREN { DESTINATION=EtherType, LLC-CHECK=llc } 



etherType 



etherData 



ethernet 
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4.2 IP Version 4 

Here is an example of the PDL for the IP protocol: 

ipAddress FIELD 

SYNTAX BYTESTRING (4) 

DISPLAY-HINT • "Id." 
LOOKUP HOSTNAME 
DESCRIPTION 

"IP address" 



ipVersion FIELD 

SYNTAX INT (4) 

DEFAULT "4" 



ipHeaderLength FIELD 
SYNTAX 

ipTypeOfService FIELD 
SYNTAX 



ipLength 

ipFlags 
dontFrag(l) } 
IpFragmentOf f set 



ipProtocol FIELD 
SYNTAX 
LOOKUP 



FIELD 
SYNTAX 



FIELD 
SYNTAX 



INT (4) 



BITSTRING(8) { minCost (1) , 
maxReliability (2) , maxThruput (3) , 
minDelay (4) } 



UNSIGNED INT (16) 
BITSTRINGO) { moreFrags (0) , 



FIELD 
SYNTAX 



INT(13) 



INT (8) 

FILE "IpProtocol .cf" 



ipData 



FIELD 
SYNTAX 

ENCAP 

DISPLAY-HINT 



BYTESTRING (0. .1500) 

ipProtocol 
"HexDump" 



ip PROTOCOL 
SUMMARIZE 

"$FragmentOf f set != 0": 

"IPFragment ID=$Identif ication 

Of f set=$FragmentOf fset" 

"Default" : 

"IP Protocol=$Protocol" 

DESCRIPTION 

"Protocol format for the Internet Protocol" 

REFERENCE "RFC 7 91" 
: := { Version=ipVersion^ HeaderLength==ipHeaderLength, 

TypeOfService=ipTypeOf Service, Length=ipLength, 
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Identif ication=UIntl6, IpFlags=ipFlags , 
FragmentOf fset=ipFragmentOf fset, TimeToLive=Int8, 
Protocol=ipProtocol, Checksum=ByteStr2, 
IpSrc=ipAcidress, IpDest=ipAddress , Options=ipOptions, 
Fragment=ipFragment, Data=ipData } 

ip FLOW 

HEADER { LENGTH=HeaderLength, IN-WORDS } 
NET-LAYER { 

SOURCE=IpSrc, 

DESTINATION=IpDest, 

FRAGMENTATI0N=IPV4, 

TUNNELING 

} 

CHILDREN { DESTINATION=Protocol } 

ipFragData FIELD 

SYNTAX BYTESTRING (1 , .1500) 

LENGTH "ipLength - ipHeaderLength * 4" 

DISPLAY-HINT "HexDump" 

ipFragment GROUP 

OPTIONAL "$FragmentOffset != 0" 
{ Data=ipFragData } 

ipOptionCode FIELD 

SYNTAX INT (8) { ipRR(0x07), 

ipTimestamp (0x44) , 

ipLSRR{0x83) , ipSSRR(0x89) } 
DESCRIPTION 

"IP option code" 

ipOptionLength FIELD 

SYNTAX UNSIGNED INT (8) 

DESCRIPTION 

"Length of IP option" 

ipOptionData FIELD 

SYNTAX BYTESTRING (0 . . 1500) 

ENCAP ipOptionCode 
DISPLAY-HINT "HexDump" 

ipOptions GROUP 

LENGTH "(ipHeaderLength * 4) - 20" 

::= { Code=ipOptionCode, Length=ipOptionLength, Pointer=UInt8, 
Data=ipOptionData } 
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4.3 TCP 

Here is an example of the PDL for the TCP protocol: 

tcpPort FIELD 

SYNTAX UNSIGNED INT (16) 

LOOKUP FILE "TcpPort. cf" 



tcpHeaderLen FIELD 

SYNTAX INT (4) 



tcpFlags FIELD 

SYNTAX BITSTRING(12) { fin(O), syn(l), rst{2), psh(3), 

ack(4), urg(5) } 

tcpData FIELD 

SYNTAX BYTESTRING (0 . . 1564) 

LENGTH " ($ipLength- ($ipHeaderLength*4 ) ) - 

($tcpHeacierLen*4) " 

ENCAP tcpPort 

DISPLAY-HINT "HexDump" 

tcp PROTOCOL 
SUMMARIZE 

"Default" : 
"TCP ACK=$Ack WIN=$WindowSize" 
DESCRIPTION 

"Protocol format for the Transmission Control 

Protocol" 

REFERENCE "RFC 7 93" 
::= { SrcPort=tcpPort , DestPort=tcpPort , SequenceNum=UInt32, 

Ack=UInt32, HeaderLength= tcpHeaderLen, TcpFlags=tcpFlags, 

WindowSize=UIntl6, Checksum=ByteStr2, 

UrgentPointer=UIntl6, Opt ions=tcpOpt ions, Data=tcpData } 
tcp FLOW 

HEADER { LENGTH=HeaderLength, IN-WORDS } 
CONNECTION { 

IDENTIFIER=SequenceNum, 

CONNECT-START="TcpFlags : 1", 

CONNEGT-COMPLETE="TcpFlags : 4 " , 

DISCONNECT-START="TcpFlags : 0" , 

DISCONNECT-COMPLETE-"TcpFlags : 4" 

} 

PAYLOAD { INCLUDE-HEADER } 

CHILDREN { DESTINATION=DestPort, SOURCE=SrcPort ) 

tcpOptionKind FIELD 

SYNTAX UNSIGNED INT (8) { tcpOptEnd ( 0 ) , tcpNop(l), 

tcpMSS (2) , tcpWscale (3) , 
tcpTimestamp (4) } 

DESCRIPTION 

"Type of TCP option" 
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tcpOptionData FIELD 

SYNTAX BYTESTRING (0 . . 1500) 

ENCAP tcpOptionKind 
FLAGS SAMELAYER 
DISPLAY-HINT "HexDump" 

tcpOptions GROUP 

LENGTH " ($tcpHeaderLen * 4) - 20" 

::= { Option=tcpOptionKind, OptionLength=UInt8, 
OptionData=tcpOptionData } 



tcpMSS PROTOCOL 

::= { MaxSegmentSize=UIntl6 } 
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4,4 HTTP (with State) 

Here is an example of the PDL for the HTTP protocol: 



httpData FIELD 

SYNTAX BYTESTRING (1 . . 1500) 

LENGTH "($ipLength - ($ipHeacierLength * 4)) - ( $tcpHeacierLen 
* 4) " 

DISPLAY-HINT "Text" 
FLAGS NOLABEL 



http PROTOCOL 
SUMMARIZE 

"$httpData m/'^GET r HTTP KHEAD r POST/" : 

"HTTP $httpData" 
"$httpData m/" [Dd] ate T [ Ss ] erver I ^ [Ll]ast- 
[Mm]odified/" : 

"HTTP $httpData" 
"$httpData m/^ [Cc] ontent-/" : 

"HTTP $httpData" 
"$httpData m/'^<HTML>/" : 

"HTTP [HTML document]" 
"$httpData m/"GIF/" : 

"HTTP [GIF image] " 
"Default" : 

"HTTP [Data]" 
DESCRIPTION 

"Protocol format for HTTP." 
::= { Data=littpData } 

http FLOW 

HEADER { LENGTH=0 } 
CONNECTION { INHERITED } 

PAYLOAD { INCLUDE-HEADER, DATA=Data, LENGTH=256 } 
STATES 

"SO: CHECKCONNECT, GOTO SI 
DEFAULT NEXT SO 



SI: WAIT 2, GOTO S2, NEXT SI 
DEFAULT NEXT SO 

S2 : MATCH 



sybaseWebsql 
sybaseJdbc 
sybaseTds 
PointCast 



' \n\r\n' 


900 


0 


0 


255 


0, 


NEXT S3 


• \n\n' 


900 


0 


0 


255 


0, 


NEXT S3 


'POST /tds?' 


50 


0 


0 


127 


Ir 


CHILD 


' .hts HTTP/1.0' 


50 


4 


0 


127 


1, 


CHILD 


' jdbc: Sybase: Tds' 


50 


4 


0 


127 


1, 


CHILD 


•PCN-The Poin' 


500 


4 


1 


255 


0, 


CHILD 


•t: BW-C-' 


100 


4 


1 


255 


0, 


CHILD backweb 



DEFAULT NEXT S3 
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PointCast 

sybaseWebsql 

sybaseJdbc 

sybaseTds 



S3: MATCH 

'\n\r\n' 

'\n\n' 

' Content-Type : ' 
•PCN-The Poin' 

't: BW-C-' 
DEFAULT NEXT SO" 



FLOW 

STATE-BASED 
FLOW 

STATE-BASED 

FLOW 

STATE-BASED 



50 0 0 0 0, NEXT S3 

50 0 0 0 0, NEXT S3 

800 0 0 255 0, CHILD mime 

500 4 1 255 0, CHILD 

100 4 1 255 0, CHILD backweb 



PointCast FLOW 

STATE-BASED 

backweb FLOW 

STATE-BASED 

mime FLOW 

STATE-BASED 
STATES 

"SO: MATCH 

'application' 900 
mimeApplication 
' audio ' 
' image ' 
' text ' 
'video' 
' x-world ' 
mimeXworld 

DEFAULT GOTO SO" 

mimeApplication FLOW 

STATE-BASED 



900 
50 
50 
50 

500 



0 0 10, CHILD 

0 0 10, CHILD mimeAudio 

0 0 10, CHILD mimelmage 

0 0 10, CHILD mimeText 

0 0 10, CHILD mimeVideo 

4 1 255 0, CHILD 



mimeAudio FLOW 

STATE-BASED 
STATES 
"SO: MATCH 

pdBasicAudio 



pdMpeg2 Audio 
pdRealAudio 



' basic ' 


100 


0 


0 


1 


0, 


CHILD 


'midi ' 


100 


0 


0 


1 


0, 


CHILD pdMidi 


' mpeg ' 


100 


0 


0 


1 


0, 


CHILD 


' vnd. rn-realaudio ' 


100 


0 


0 


1 


0, 


CHILD 


' wav' 


100 


0 


0 


1 


0, 


CHILD pdWav 


•x-aiff ' 


100 


0 


0 


1 


0, 


CHILD pdAiff 
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' x-midi ' 
' x-mpeg ' 

pdMpeg2Auclio 

• x-mpgurl * 

pdMpeg3Audio 

' x-pn-realaudio ' 

pdRealAudio 

' x-wav ' 
DEFAULT GOTO SO" 

mimelmage FLOW 

STATE-BASED 

mimeText FLOW 

STATE-BASED 

mimeVideo FLOW 

STATE-BASED 

mimeXworld FLOW 

STATE-BASED 

pdBasicAudio FLOW 

STATE-BASED 

pdMidi FLOW 

STATE-BASED 

pdMpeg2 Audio FLOW 

STATE-BASED 

pdMpegSAudio FLOW 

STATE-BASED 

pdRealAudio FLOW 

STATE-BASED 

pdWav FLOW 

STATE-BASED 

pdAiff FLOW 

STATE-BASED 



100 


0 


0 


1 


0, 


CHILD 


pdMidi 


100 


0 


0 


1 


0, 


CHILD 




100 


0 


0 


1 


0, 


CHILD 




100 


0 


0 


1 


0, 


CHILD 




100 


0 


0 


1 


0, 


CHILD 


pdWav 
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5. Supplemental Products 

MeterWorks is supported by an optional Simple Network Management Protocol 
(SNMP) implementation. Envoy simplifies the process of porting MeterWorks to any 
platform. The MeterWorks SNMP Method Routines are written to directly 
interoperate with the Envoy product. 

In addition, Envoy is supported by Emissary, Epilogue's optional MIB Compiler 
product. The MIB Compiler is a tool that greatly simplifies the creation and 
maintenance of proprietary MIB extensions. MeterWorks also takes direct advantage 
of the Emissary MIB compiler for making changes in the RMON groups that are 
supported. 

Attache, Epilogue's Portable UDP/IP protocol stack, complements MeterWorks and 
Envoy in environments that do not already provide a protocol stack for use by SNMP. 
Attache version 3.0 provides full integration with MeterWorks version 4.00 and Envoy 
version 5.2, and fully implements MIB II (RFC 1213). 
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Exhibit B9: State-based Sub-Classification Overview (document MFS-State- 
CIassification.pdf) that describes the states of some of the protocols that are 
supported. 
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No part of its content may be used, copied, disclosed or conveyed to any party in any 
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1. Introduction 

MeterFlow allows for a very rich set of protocol classification and sub-classification in 
the process of analyzing and interpreting Network Traffic. MeterFlow accomplishes 
this by combining the maintenance of state information with a robust ability to 
interpret network data streams. 

Without the abihty to maintain state, an increasingly large amount of Network Traffic 
will be misclassified, partially classified, or not classified at all with present traffic 
analysis and interpretation technologies. Pattern matching parser techniques employed 
in many such contemporary technologies provide little help here given the growing 
complexity of today's Network Traffic. 

Misclassification is frequent given the practice of using assigned (or otherwise well- 
known) port/socket numbers as ephemeral ports/sockets. This has become especially 
noteworthy with the increasing proliferation of Web Browsers and MS WinSock. For 
example, BackWeb push-technology and Streamworks or VDOLive multimedia clients 
can use UDP ports that are either assigned to or used as defacto standards by other 
Network Applications such as Citrix, H.323 Gatekeeper, RealAudio, etc. 

Partial classification is a common limitation in traffic analysis when the scope of 
interpretation is limited to a single packet. For example, one could see TCP Port 
#1527 referenced in a network packet and know that is was an Oracle TNS Packet. 
Without having interpreted the initial Oracle TNS protocol exchange spanning multiple 
packets, one could not have known that it was indeed PeopleSoft running over 
SQL*Net running over Oracle TNS. 

Another example is of partial classification is simple "IP Fragmentation". Decoding 
the first fragment of an IP Datagram could easily determine that it further contained 
NFS over SunRPC over UDP. However, since subsequent fragments do not contain 
the UDP or SunRPC headers, they cannot be sub-classified for these protocols without 
having retained state and decoding information from the original (or first) fragment. 

The inabihty to classify is becoming increasingly common as Network Applications use 
dynamic mechanisms to allocate and assign resources to various applications. There 
are a number of ways this can happen. 

• In many cases, connections are established on a ''truly" well-known port/socket of 
a server. The exchange on this connection serves to negotiate services 
requested/available and the address/port at which those services can be accessed. 
A second connection on the allocated/assigned address and port (almost always 
ephemeral) carries the bulk or volume of the data in the overall Network Session. 
Without the ability to interpret and analyze "data" in such allocation/assignment 
protocols connections, the volume traffic on the secondary connections cannot be 
distinguished from any other "un-interpretable" traffic. Microsoft's Endpoint- 
Mapper, SunRPC's Portmapper, and Oracle TNS are examples of such protocols. 
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• In other cases, available services and their locations (addresses and ports/sockets) 
are periodically announced. Without having interpreted and remembered the 
content of such announcements, traffic to/from them cannot be classified. Novell 
SAP and Apple's Name Binding Protocol (NBP) are examples of such 
announcement-based approaches. 

The art of traffic classification becomes further complicated when a multitude of the 
imderlying challenges described above occurs for the same Network Data events. For 
example, NFS version 1 is transferring one of its typical 32-Kbyte blocks of data in a 
single IP Datagram and is hence fragmenting it (partial classification scenario). This 
transfer is occurring on an "ephemeral" UDP port of the server that was allocated via 
an initial exchange with the SunRPC Portmapper protocol (no classification scenario). 
Or, even worse, the "ephemeral" UDP port on the server tums out to be the same as 
one of the defacto standard UDP ports that "RealAudio" uses (mis-classification 
scenario). 

MeterFlow surmounts these challenges to provide accurate and thorough network 
traffic classification. This document discusses the currently supported and in-progress 
traffic classification capabilities of MeterFlow. It also presents the how MeterFlow 
may be extended to support further sub-classifications. 
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2. Protocol Classification 

2.1 Current Protocol Classifications 

MeterFlow currently includes support for classification and sub-classification of the 
following protocols, each of which are described in more detail in Section 3.0. In- 
progress developments to enhance or extend the sub-classification capabilities for 
these protocols are also described in Section 3.0. 



1. 


IP Fragmentation 


2. 


Microsoft Endpoint-Mapper 


3. 


SunRPC Portmapper 


4. 


Oracle 6/7 Transparent Network Substrate (TNS) 


5. 


H.323 Video Conferencing 


6. 


HTTP 


7. 


BackWeb 



2.2 In-Progress Protocol Classifications 

Several new state-based protocol classification and sub-classification capabilities are 
under development. These protocols include the following and are described further in 
Section 4.0. 

1 . Real-Time Streaming Protocol (RTSP) 

2. Novell Service Advertising Protocol (SAP) 

3. MS Media 

4. Streamworks and VDOLive 
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3. Current Protocol Classification 

3.1 IP/IPIP/IPIP4 Fragmentation 

3.1.1 Features 

Fragmentation support for the Internet IP protocol is implemented in three MeterFlow 
sub-engines, each of which supports state maintenance and sub-classification retention 
for network packet fragments associated with the following protocols: 

1 . IP - Internet Protocol Version 4 datagram fragments 

2. IPIP - IPIP datagram fragments Tunneled over IP 

3. IPIP4 - IPIP4 datagram fragments Tunneled over IP 

Key capabilities of these sub-engines include: 

1 . Tracking fragments for their corresponding protocols 

2. Passing on 1'' fragments through normal decoding and state-based decoding 

3. Retaining complete I'^ fragment sub-classification information for datagrams which 
are not further classified as state based (e.g. NFS Version 2 over UDP on well- 
known port 2049) and applying this information to all subsequent fragments 
components. 

4. Retaining flow references for fragment sub-classifications that further classify as 
state-based (e.g. Oracle TNS over TCP on a redirected, ephemeral port) and 
updating such flows for all subsequent fragment components. 

5. Supporting concurrent fragmentation of data across multiple layers of Tunneling 
(e.g. IPIP4 fragments contained in IP fragments). 

3.1.2 Sub-classifications 

These sub-engines don't really "classify" or "sub-classify" underlying protocols 
contained in fragments beyond that normally done by the standard IP Version 4 
decoding of the "protocol type". They do however retain "sub-classification" 
information or flow references as described above in Section 3.1.1. 

3.1.3 Extensibility 

By the nature of their scope, these sub-engines are not extensible beyond that which 
may be applied to standard IP Version 4 decoding with respect to the addition of new 
"Protocol Types". 

3.1.4 Planned Developments 

The "Internet Fragmentation Sub-Engines" will eventually add support for IP Version 
6. 
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3.2 Microsoft Endpoint-Mapper 

3.2.1 Features 

The Microsoft Endpoint-Mapper actually supports the Endpoint-Mapper protocol 
defined by the ''Distributed Computing Environment (DCE) 1.1 - Remote Procedure 
Call' specification. The key node point in the protocol directory for this protocol, 
and related applications determined by its mappings, is ''endpoint-mapper'\ 

Key capabilities of this sub-engine include: 

1 . Tracking connections to and exchange within the well-known Endpoint-Mapper. 

2. Distinguishing such "mapping" traffic fi-om traffic on application connections 
subsequently "mapped". 

3. Detecting assignments of server application access assignments to various hosts 
and/or ports and creating sub-classifications for these access points. 

4. When traffic to these access points is seen, it will be classified 

a) By the appropriate application under ''endpoint-mapper'\ if the server 
application identifier in the mapping exchange is a known sub-application. 

b) Minimally as ''endpoint-mapper'\ if the server application is unknown. 

5. Allowing known sub-applications to be specified with respect to flow reporting 
with two levels of identification 

a) Level 1 - Endpoint Mapped "Application Group" 

b) Level 2 - Sub-application within the Application Group 

6. Supporting the "connection-oriented" mode of Endpoint-Mapper operations. 

3.2.2 Sub-classifications 

Sub-classifications under "endpoint-mapper" include the following in both the "/cp" 
and "m(3^" protocol subtrees: 

endpoint-mapper dcerpc-mapper (DCE RFC - Endpoint Mapping) 

-> ms-exchange directory (MS-Exchange Directory) 

-> information-store (MS-Exhange Information Store) 
-> mta (MS-Exchange MS-Mail MTA) 

3.2.3 Extensibility 

New Sub-classifications are easily added as new entries in the DCE RPC Sub-Engine's 
"Sub-Protocol Info" table, if the Universallv Unique IDs TUUIDs) of the 
corresponding applications are known. 



j 



Technically Elite, Inc. 



9 



Proprietary and Confidential 



Version A0.03 



3.2.4 Planned Developments 

Certainly there are more applications out there other than MS-EXCHANGE using 
DCE-RPC (also known as MS-RPC or Microsoft RPC since Microsoft adopted this 
RFC standard as opposed to SunRPC). As more notable applications are identified 
along with their assigned UUIDs, they will be added to the MeterFlow 
implementation. 

Microsoft Exchange under the UDP instance of "endpoint-mapper*' probably isn't 
really a valid possibihty. Accordingly, it will probably be removed from this instance. 

Support for the ''connection-less" mode of Endpoint Mapper operation could become 
a candidate for implementation when and if it can be determined that someone is 
indeed using it in the real world. 
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3.3 SunRPC Portmapper 

3.3. 1 Features 

The SunRPC Portmapper protocol is defined by the "RPC: Remote Procedure Call 
Specification Version 2 (RFC 1831)" standard. The key node point in the protocol 
directory for this protocol, and related applications determined by its mappings, is 
"sunrpc". 

Key capabilities of this sub-engine include: 

1 . Tracking exchanges with the well-known SunRPC Portmapper. 

2. Distinguishing such "mapping" traffic firom traffic on application connections 
subsequently "mapped". 

3. Detecting assignments of server application access assignments to various hosts 
and/or ports and creating sub-classifications for these access points. 

4. When traffic to these access points is seen, it will be classified 

(a) By the appropriate application under ''sunrpc'\ if the server application 
identifier in the mapping exchange is a known sub-application. 

(b) Minimally as ''sunrpc'\ if the server application is unknown. 

5. Allowing known sub-applications to be specified with respect to flow reporting 
with a single levels of identification 

(a) Level 1 - Portmapped "Application" 



3.3.2 Sub-classifications 

Sub-classifications under "sunrpc" include the following in both the "tcp" and "udp" 
protocol subtrees: 



sunrpc -> portmapper 
^ rstat 

ypserv 
ypbind 
ypupdated 

-> ypxferd 

-> mount 

3270-mapper 

rje-mapper 

nis 



(SunRPC - Port Mapping) 
(remote statistics) 
(network file service) 
(yellow pages - server) 
(yellow pages - bindings) 
(yellow pages - update daemon) 
(yellow pages - transfer daemon) 
(remote file system mount) 
(3270 terminal session mapper) 
(remote job entry session mapper) 
(next generation yellow pages) 
(pcNFS daemon) 



pcnfsd 
3.3.3 Extensibility 

New Sub-classifications are easily added as new entries in the SunRPC Sub-Engine's 
"Sub-Protocol Info" table, if the SunRPC Program Number of the corresponding 
applications are known. 
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3.3.4 Planned Developments 

Certainly there are still other applications using SunRPC. As more notable 
applications are identified along with their assigned SunRPC Program Numbers, they 
will be added to the MeterFlow implementation. 

Enhancement of the SunRPC Sub-Engine to additionally support SET, UNSET, 
DUMP, and/or CALLIT SunRPC Portmapper primitives could become a candidate for 
implementation when and if it can be determined that someone is indeed using them in 
the real world. 

Improved understanding of whether the supported SunRPC sub-applications run over 
just UDP or TCP will enable the "sunrpc" sub-classifications to be more accurately 
categorized with respect to the protocol it actually runs over. For example, 
"portmapper", "nfs", and "pcnfsd" all operate only over UDP. Accordingly, their 
presence in the TCP subtree for "sunrpc" is unnecessary. 
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3.4 Oracle 6/7 Transparent Network Substrate (TNS) 

3,4.1 Features 

The Transparent Network Substrate (TNS) protocol is defined by Oracle Corporation 

and is used as the underlying networks access framework for its Oracle Version 6 and 
Oracle Version 7 database product offerings. The key node points in the protocol 
directory for this protocol and applications determined by its mappings are "oracl-tns'\ 
"oracl-tns2", "oracl-tns-srv". These three node points reflect the three different 
"well-known" ports that serve to support initial access to Oracle TNS on Oracle 
Database servers. The first is a defacto, Oracle standard use. The next two access 
points (TCP ports) are assigned to Oracle by lANA. 

Key capabilities of this sub-engine include: 

1. Tracking connections to and exchanges in well-known Oracle TNS port traffic. 

2. Learning the client application attempting to access the Oracle Database (e.g. 
PeopleSoft, Oracle Forms, etc.) to further classify traffic on the well-known Oracle 
TNS connections. 

3. Detecting "redirections" of connections to various hosts and/or ports and creating 
sub-classifications for these access points. Such "redirections" inherit the sub- 
classifications of the initial connections to the well-known Oracle TNS service. 

4. When traffic to these access points is seen or when TNS sessions are "accepted" 
on the well-know TNS service port, it will be classified 

(a) By the appropriate client application under ''oracle-tns'' (or ''oracl- 
tns2'' or ''oracl-tns-srv), if the client application identifier is a known 

sub-application. 

(b) Minimally as "oracle-tm'' (or ''oracl-tns2'' or ''oracl-tns-srv), if the 
server application is unknown. 

5. Allowing known sub-applications to be specified with respect to flow reporting 
with two levels of identification 

(a) Level 1 - Oracle cHent's "Application Group" 

(b) Level 2 - Sub-apphcation within the Application Group 
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3.4.2 Sub-classifications 

Sub-classifications under "oracle-tns" include the following in the "tcp" subtree. Note 
that the same sub-classification occurs under the "oracl-tns2" and "oracl-tns-srv" 
nodes as well. 



3.4,3 Extensibility 

New Sub-classifications are easily added as new entries in the Oracle TNS Sub- 
Engine's "Sub-Protocol Info" table, if the Program Names (or names of the client 
programs' executables) of the corresponding client applications are known. 

3AA Planned Developments 

Further sub-classification of "PeopleSoft" is highly desired. Namely, breaking 
"peoplesoft" down into component applications. 

Certainly there are still other native, client applications using Oracle TNS. As more 
notable applications are identified along with their assigned Program/Executable 
Names, they will be added to the MeterFlow implementation. 

"SAP R/3" and "Baan", in particular, are high priority applications to establish such 
additional support for. 

A major enhancement to the Oracle TNS sub-engine will be to fiirther build upon the 
application sub-classification capabiHties presently supported. This will allow the sub- 
engine to fiirther delve into the SQL*Net content to determine the actual client 
applications riding atop 4GL tools (such as Oracle FORMs) and access APIs (such as 
MS ODBC, and MS OLE). 

The three Oracle TNS subtrees ("oracle-tns", "oracl-tns2", and "oracl-tns-srv) will 
most likely be consolidated under a single subtree under TCP ("oracle-tns"). 
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-> ms'ole 

-> oracle-sqlplus 
oracle-forms 
peoplesoft 



(Microsoft ODBC) 
(Microsoft OLE) 
(Oracle SQLPlus) 
(Oracle FORMS) 
(PeopleSoft) 



MeterFlow State-based Sub-classification 



Version A0.03 



3.5 H.323 Videoconferencing 

3.5.1 Features 

H. 323 is an umbrella standard published by the International Telecommunication 
Union (ITU, formerly CCITT) for videoconferencing. H.323 entails one of the most 
complicated traffic classification challenges of today's networking protocols. This 
arises form its inherent multi-tier connection/data-stream architecture. 

In H.323, connections are initially established on a well-known service port. The 
Q.931 protocol is used on this "H.323 Call Setup" connection to set-up a second 
connection on an ephemeral port. The second "H.323 Call Control" connection uses 
the H.245 protocol to negotiate audio and video capabilities (codecs) as well as to 
further set-up RTP/RTCP audio and video data streams over ephemeral UDP ports. 

Key capabilities of this sub-engine include: 

I . Tracking connections to and exchanges on well-known H.323-host-call port 
(Q.931 protocol) traffic. 

2. Detecting assignments of H.245 access points to various hosts and/or ports and 
creating H.245 sub-classifications for these access points. 

3. Tracking cormections to and exchanges with such assigned H.245 access points. 

4. Detecting the assignment of RTP/RTCP audio and video, UDP datastreams access 
points as well as the audio and video "codecs" negotiated for use on them and 
creating RTP/RTCP sub-classifications for these access points. 

5. When traffic to these RTP/RTCP access points are seen it will be classified 

(a) By the appropriate "codec" under "r//? if the negotiated codec is a 
known audio/video stream type. 

(b) Minimally as "rrp", if the negotiated codec is unknown. 

6. Allowing known sub-applications (audio/video datastreams) to be specified with 
respect to flow reporting with three levels of identification 

(a) Level 1 -Datastream Class (e.g. audio, video, other...) 

(b) Level 2 - Datastream Type within the Datastream Class 

(c) Level 3 - Datastream Sub-Type within the Datastream Type 

7. Supporting the Q.93 1 "normal mode" of operation for "H.323 Call Setup 
connections". 
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3.5.2 Sub-classifications 



"H.323 Call Setup" Sub-classifications under "h323-host-caU" include the following in 
the "tcp" subtree. 



h323-host-call 



-> q931 

q931 -fast-start 



(H.323 Call Setup) 

(H.323 Combined Setup and Control) 



"H.323 Call Control" Sub-classifications under "h323 -host-control" include the 
following in the "tcp" subtree. 



h323-host-control 



■» li245 



(H.323 Call Control) 



Audio and video datastream Sub-classifications under "RTP/RTCP" include the 
following in the "udp" subtree. 



RTCP ^ 

RTP -> audio 



video 



^ G.7]l 

G. 722 

G.728 
^ G.729 

MPEGl-audio 

G. 723 
^ GSM 
-> H.261 

H. 263 



(Audio/Video Stream Control sub-channel) 
(Audio Transfer sub-channel) 



(Video Transfer sub-channel) 



QCIF 
^ CIF 
-> SQCIF 
^ QCIF 
^ CIF 
•^4CIF 
-» I6CIF 

->MRV 

Standards for the audio stream sub-classifications indicated above are: 

G.711 - 64 Kbps, 8K samples/sec, 8-bit companded PCM (A-law or \i -law), high 
quaHty, low complexity. Required for H.320 and H.323. 

G.722 - ADPCM audio encode/decode (64 kbit/s, 7 kHz) . 

G.723 - Speech coder at 6.3 and 5.3 Kbps data rate. Medium complexity. Required 
for H.324; Optional for H.323. 

G.728 - 16 Kbps, LD-CELP, high quality speech coder, very high complexity. 
Optional for H.320 and H.323. 

G.729 - 8Kbps, LD-CELP, high quality speech coder, medium complexity. G.DSVD 
is an interoperable subset. 

GSM - Group Special Mobile - European telephony standard, not ITU. Used by 
ProShare Video Conferencing software versions 1.0-1.8. 13Kbps, medium 
quality for voice only, low complexity. 
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Standards for the video stream sub-classifications indicated above are: 

H.261 - Supports 352x288 (GIF or FCIF) and 176x144 (QCIF). DCT-based 

algorithm tuned for 2B to 6B ISDN communication. Required for H.320, 
H.323, and H.324. 

H.263 - Much-improved derivative of H.261, tuned for POTS data rates. Mostly 

aimed at QCIF and Sub-QCIF (128x96 - SQCIF). Optional for H.323 and 
H.324, although industry is focusing on it for POTS. Being added as an 
option to H.261. 

MRV - Intel Indeo® video compression technology tuned for ISDN and LAN data 
rates. 

3.5.3 Extensibility 

New Sub-classifications are easily added as new entries in the H.323 Sub-Engine's 
"Sub-Protocol Info" table, if the AudioA^ideo Capabilitv Identifiers of the 
corresponding audio/video datastream are known. 

3.5.4 Planned Developments 

There are still more audio/video datastream formats. As others are* identified along 
with their assigned capability identifiers , they will be added to the MeterFlow 
implementation. 

There is a mode of H.323 operation defined called "Q.931 Fast Start". In this mode, 
"H.323 Call Control" operations (normally performed under their own H.245 
connection) are piggybacked over Q.93 1 in the "H.323 Call Setup" connection. The 
use of this mode of operation has historically been rare and infi-equent in contemporary 
videoconferencing products. The H.323 sub-engine will be enhanced to support this 
mode of operation. 
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3.6 HTTP 

3.6.1 Features 

The HTTP Protocol is the basis of common, present-day Web Browsers and has 
become a fundamental transport mechanism for many Internet applications. HTTP 
operates over TCP connections. Traditional/typical use of HTTP involves the 
establishment/tear-down of an individual HTTP connection for each element of 
exchange in a given user session activity (e.g. a web page will involve many TCP 
connections to effect the transfer of the various components of the activity). 

There are two ways to distinguish the nature of the application information involved in 
an HTTP exchange. 

1. HTTP content type 

2. Interpretation of various fields in the HTTP data 
Key capabilities of this sub-engine include: 

1 . Tracking connections to and exchanges in well-known HTTP Port traffic. 

2. Learning the nature of the application data being transferred or accessed to further 
classify traffic on such well-known HTTP connections. 

3. Learning the nature of the application by virtue of analyzing selected HTTP fields. 

4. Allowing known sub-applications to be specified with respect to flow reporting 
with two levels of identification 

(a) Level 1 - HTTP sub-application group (e.g. database, application, 
video, etc..) 

(b) Level 2 - sub-application within the sub-application group 

5. Classifying HTTP traffic 

(a) By the appropriate sub-application within the sub-application group, if 
the sub-application identifier is known. 

(b) Minimally by the sub-application group, if the negotiated sub- 
application identifier is unknown. 
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3.6.2 Sub-classifications 

Sub-classifications under ''www-http'' include the following in the "/c/?" subtree. Note 
that the same sub-classification occurs under the ''alternate-http'' node as well. 

www-http database sybase-web-sql 

-> Sybase- tunneled-tds 

jdbc -> odbc- bridge 

-> ibm-db2 
giipta-jdbc 
sybase-Jdbc 

application pointcast 
bachveb 
datawindow 
edi-content 

^ edifact 
-> exec/ 

-> macbinhex40 
-> wpi 

mspowerpoint 
-> msword 
-> news-message-id 

news-transmission 
-> octet-stream 

postscript 
powerbuilder 
quattro-pro 
•^rtf 
Jgw/ 

vnd-framemaker 
-> vnd'lotus- 1-2-3 

vnd-lotus-approach 

vnd-htus'freelance 

vnd-lotuS'Organizer 

vnd-lotuS'Wordpro 

vnd-mif 

vnd-ms-excel 
-> vnd-ms-powerpoint 

vnd-ms'project 

vnd-ms-word 
-> vnd'Werbiiilder 

vnd-rn-realplyer 

vnd-visio 
■> WordPerfect • 

X'bcpio 
-> X'Compress 

X'Cpio 

-> x-director 

jr-<^v/ 
-> x-gtar 

x-Javascript 

X'latex 

X'lotiis-notes 

x-macbinary 
-> j:-w// 

x-pncmd 

x-pn-realatidio 
-> X'powerpoint 
-^X'Sh 

x-stuffit 

jc-/or 
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WMW-http 

(com.) 



application 
(cant.) 



audio 



image 



x-tex 
-> X'troff 
x-ustar 

x-zip-conipressed 

-> zip-archive 
x-netcdf 

-> m/W; 

vnd-rn-reaiaudio 

x-midi 
-> x-mpeg 
x-mpgurl 
x-pn-realaudio 

Jf->VOV 

-^Jpeg 
p/c/ 
^p«g 

•> vnd-rn-realflash 
-> vnd-m-realpix 
-> x-bitmap 

x-pixmap 

x-qidcktime 

X'windowdump 

X'Xbm 



X'World 



-> enriched 
->html 

-> richtext 

-> 5g/l// 

-> tab-separated'Value 
-> vnd-rn-text 

-> CJ5 

msvideo 
ms-video 
quicklime 
vnd'rn-realvideo 
vnd-vivo 
X'ls-asf 
-> x-ls-asx 
x-mpeg 
x-ms-asf 

x-ms video 
x-sgi-movie 

-> X'Vrml 
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3.6.3 Extensibility 

New Sub-classifications require much more thought and analysis when being added to 
HTTP. This arises from the following factors: 

1 . HTTP is a "text" based protocol 

2. To support "minimum" execution overhead, when searching the HTTP Sub- 
Engine's "Sub-Protocol Info" database, a rather robust set of sequentially indexed, 
look-aside tables are employed. 

(a) The challenge here is to take a string from an HTTP packet (e.g. 
Content Type) and match it with any one of approximately 1 10+ well 
known (as is the case with Content Type) 

(b) And to do so within an embedded environment that is trying to keep up 
with the network packet rate at Ime speed. 

(c) The supported search mechanism can identify a single match candidate 
sub-string by looking at typically no more than 3 to 5 charactere of the 
sub-string from the HTTP packet. 

3. Adding a sub-classification to the HTTP "Sub-Protocol Info" Database is simply a 
matter of adding a new entry if the "Content Type" or "JDBC URL Component" is 
known. 

4. Updating and/or extending the "look-aside" tables requires extreme caution and 
accuracy. 

Extensibihty for this sub-engine will be tremendously improved when the PDL 
compiler is incorporated for this sub-engine. 

3.6.4 Planned Developments 

New "Content Types" are springing up ahnost every week. As new applications are 
identified along with their designated Content Types, they will be added to the 
MeterFlow implementation. 

WebNFS from Sun Microsystems, Inc. Uinnels NFS file access over HTTP and is a 
clear candidate for inclusion into this sub-engine. 

There are many other JDBC packages from various database manufacUires and 
technology suppliers that are integrated with WWW. Oracle's being the most noted at 
this time. As more are identified along with their designated JDBC URL Selectors, 
they will be added to the MeterFlow implementation. 
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3.7 BackWeb 

3.7.1 Features 

BackWeb (BackWeb Technologies, Inc.) is a news/broadcast application. It may be 
configured to operate in either of 2 modes: 

a) HTTP only (see Section 3.6 above) 

b) UDP for access to BackWeb Servers & HTTP to access to 3'"* party channels 
(polite mode) 

BackWeb operates over UDP in what it calls its "Polite Client" mode. In this mode, 
BackWeb has an unusual mechanism of exchange that makes traffic in one direction 
very easy to see (well-knov^^n), but difficult to classify in the other direction. 

The BackWeb sub-engine has been implemented specifically for BackWeb's UDP 
(Polite Mode) access protocol 

Key capabilities of this sub-engine include: 

1 . Tracking exchanges with BackWeb Servers in well-known BackWeb Server port 
traffic. 

2. Remembering the access points of traffic from BackWeb Clients and creating sub- 
classifications for these access points. 

3. When traffic to these access points are seen, it will be classified 

(a) as "backweb" 

3. 7. 2 Sub-classifications 

BackWeb (Polite Mode) traffic is classified as "backweb" in the 'Hidp" subtree. No 
fiirther sub-classifications for BackWeb are supported. 

3.7.3 Extensibility 

There are no known Sub-Classifications to be supported for BackWeb at this time. 

3.7.4 Planned Developments 

No fiuther development efforts are currently planned for the BackWeb sub-engine. 
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4. In-Progress Protocol Classification 

4.1 Real-Time Streaming Protocol (RTSP) 

4,1.1 Features 

The "Real-Time Streaming Protocol" is defined in RFC 2326. Like HTTP it is a 
"text" based protocol. Unlike HTTP, its principle purpose is to enable the controlled, 
on-demand delivery of real-time data, such as audio and video. 

In function it acts similar to H.323's "Call Setup" and "Call Control" services, 
however, in a single connection on a well-known port. Ultimately, it serves to set up 
RTP/RTCP datastreams over UDP. 

Key capabilities of this sub-engine include: 

1 . Tracking exchanges with the well-known RTSP server. 

2. Detecting the assignment of RTP/RTCP audio and video, UDP datastreams access 
points as well as the audio and video "codecs" negotiated for use on them and 
creating RTP/RTCP sub-classifications for these access points. 

3. When traffic to these RTP/RTCP access points are seen it will be classified 

(a) By the appropriate "codec" under "r//?", if the negotiated codec is a 
known audio/video stream type. 

(b) Minimally as "r/p", if the negotiated codec is unknown. 

4. Allowing known sub-applications (audio/video datastreams) to be specified with 
respect to flow reporting with three levels of identification 

(a) Level 1 - Datastream Class (e.g. audio, video, other...) 

(b) Level 2 - Datastream Type within the Datastream Class 

(a) Level 3 - Datastream Sub-Type within the Datastream Type 
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4,1.2 Sub-classifications 

RTSP traffic will be classified as "rtsp" in the "tcp" subtree. No further sub- 
classifications for RTSP are supported. 

NEW Audio and video datastream Sub-classifications under "RTF" will include the 
following in the "udp" subtree. 

RTP audio -^1016 (Audio Transfer sub-channel) 

-> DVI4 
-^18 
-^116 
-^LPC 

-> VDVI 
-> AIFF-C 



video -> CelB (Video Transfer sub-channel) 

-^MPV 
->MP2T 
nv 



Standards for the audio stream sub-classifications indicated above are: 

1016 - fi-ame based encoding using code-excited linear prediction (CELP) and is 
specified in Federal Standard FED-STD 1016 

DVI4 - IMA ADPCM wave type, "IMA Recommended Practices for Enhancing 
Digital Audio Compatibility in Multimedia Systems (version 3.0)" 

L8 - L8 denotes linear audio data, using 8-bits of precision with an offset of 128, 
that is, the most negative signal is encoded as zero. 

LI 6 - L16 denotes uncompressed audio data, using 16-bit signed representation 
with 65535 equally divided steps between minimum and maximum signal 
level, ranging from -32768 to 32767. The value is represented in two's 
complement notation and network byte order. 

LPC - LPC designates an experimental linear predictive encoding contributed by 

Ron Frederick, Xerox PARC, which is based on an implementation written by 
Ron Zuckerman, Motorola, posted to the Usenet group comp.dsp on June 
26, 1992. 

MPA - MPA denotes MPEG-I or MPEG-II audio encapsulated as elementary 

streams. The encoding is defined in ISO standards ISO/IEC 1 1 172-3 and 
13818-3. The encapsulation is specified in work in progress. 

VDVI - VDVI is a variable-rate version of DVI4, yielding speech bit rates of between 
10 and 25 kb/s. It is specified for single-channel operation only. 
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AIFF-c - Apple Computer, "Audio interchange file format AIFF-C," Aug. 1991. (also 
ftp://ftp.sgi.eom/sgi/aiff-c.9.26.9 1 .ps.Z). 

Standards for the video stream sub-classifications indicated above are: 

CelB - The CELL-B encoding is a proprietary encoding proposed by Sun 

Microsystems. "RTF payload format of CellB video encoding," Work in 
Progress, Internet Engineering Task Force, Aug. 1995. 

JPEG - The encoding is specified in ISO Standards 10918-1 and 10918-2. 

MPV - Designates the use MPEG-I and MPEG-II video encoding elementary 
streams as specified in ISO Standards ISO/IEC 11 172 and 13818-2, 
respectively. 

MP2T - MP2T designates the use of MPEG-II transport streams, for either audio or 
video. 

nv - The encoding is implemented in the program W, version 4, developed at 
Xerox PARC 

4,1.3 Extensibility 

New Sub-classifications will easily added as new entries in the RTSP Sub-Engine's 
"Sub-Protocol Info'* table, if the Pavload Tvpes of the corresponding audio/video 
stream are known. 
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4.2 Novell Service Advertising Protocol (SAP) 

4.2.1 Features 

The Novell Service Advertising Protocol (SAP) is a protocol similar in nature to the 
"SUN RPC Portmapper" protocol. It is used to support the dynamic management and 
locating of "services" with regards to their locations (network addresses) and port 
assignments. 

SAP uses a completely different protocol than the SUN RPC protocol Portmapper. 
Also, a fundamental difference from Sun RPC is that SAP periodically broadcasts 
services that are in it's advertising database. 

Key capabilities of this sub-engine include: 

1 . Tracking SAP announcements periodically broadcast by Novell Netware servers. 

2. Distinguishing such "announcement" traffic from traffic on application connections 
subsequently "mapped". 

3. Detecting assignments of server application access assignments to various hosts 
and/or sockets and creating sub-classifications for these access points. 

4. When traffic to these access points is seen, it will be classified 

(a) By the appropriate application under "wov-^a/?", if the server 
application identifier in the announcement is a known sub-application. 

(b) Minimally as ''nov-sap'\ if the server application is unknown. 

5. Allowing known sub-applications to be specified with respect to flow reporting 
with a single levels of identification 

(a) Level 1 - SAP Mapped "Application Group" 

(b) Level 2 - Sub-application within the Application Group 
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4.2.2 Sub-classifications 

Sub-classifications under "nov-sap" will include the following in the "ipx.nov-pep" 
subtree. 



nov'sap announce 

ms-exchange 
sybasejsqlany 
Sybase _sqlenterprise 

-> gupta-sqlbase 
ms-sna-server 
ms-sql-server 
citrix-app-server 
citrix-app-server-nt 
hp'laserjet 
advertising'print'Svr 
netware-sql'Server 

-> remote-bridge 
bridge-server 
print-queue 



(Novell SAP Announcements) 
(Microsoft Exchange) 
(Sybase SQL Anywhere) 
(Sybase SQL Enterprise) 
(Gupta SQLBase) 
(Microsoft SNA Server) 
(Microsoft SQL Server) 
(Citrix Application Server) 
(Citrix Application Sei^ver for NT) 
(HP Laserjet Printer) 
(Advertising Print Server) 
(Novell Netware SQL Server) 
(Remote Bridge Router Service) 
(Bridge Server) 
(Print Queue Server) 



4,2.3 Extensibility 

New Sub-classifications will easily added as new entries in the Novell SAP Sub- 
Engine's "Sub-Protocol Info" table, if the SAP IDs of the corresponding application 
are known. 
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4.3 MS-Media 

4.3.1 Features 

MS-Media is a audio/video streaming, multimedia application (similar to RealAudio) 
from Microsoft. MS-Media may be configured to operate over UDP when 
transferring its payload. In this configuration, MS-Media has an unusual mechanism to 
allocate UDP resources for this purpose via an initial TCP connection. 

The MS-Media sub-engine will be implemented specifically for MS-Media's access 
protocol 

Key capabiUties of this sub-engine include: 

1. Tracking connections to and exchanges in well-known MS-Media port traffic. 

2. Detecting assignments of UDP access points to various hosts and/or ports and 
creating MS-Media sub-classifications for these access points. 

3. When traffic to these access points are seen, it will be classified 

(a) as "ms-media" 

4.3.2 Sub-classifications 

Such MS-Media traffic will be classified as ''ms-medid' in the "wc//?" subtree. No 
further sub-classifications for MS-Media will be initially supported. 

4.3.3 Extensibility 

Sub-Classification is beyond the initial scope of the MS-Media sub-engine. 
Eventually, the sub-engine will be able to sub-classify the types of payloads being 
transferred. 
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4.4 Streamworks and VDOLive 

4.4.1 Features 

Streamworks and VDOLive are multi-media, streaming applications which transfer 
their payloads over UDP. 

Like BackWeb, Streamworks and VDOLive employ unusual mechanisms of exchange 
that makes traffic one direction very easy to see (well-known), but difficult to classify 
in the other direction. 

The BackWeb sub-engine will be expanded to further support Streamworks and 
VDOLive classification. 

For a description of the key capabiHties of the sub-engine, see Section 3.7: 

4.4.2 Sub-classifications 

Streamworks and VDOLive traffic is classified as "streamworks-xing-mpeg" and 
"vdolive" in the "udp" subtree; respectively. No further sub-classifications for these 
protocols will be supported. 

4.4.3 Extensibility 

Sub-Classification is beyond the initial scope Streamworks and VDOLive. Eventually, 
the sub-engine will be able to sub-classify the types of payloads being transferred. 
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